VidHD Firmware Bug? [message #381701] |
Thu, 07 March 2019 16:27 |
|
Originally posted by: James Kruth
I've been loving the VidHD, but I think I may have found a firmware bug. I've got the card in slot 3 of my ROM 3 IIgs and have been running with the "Your Card" setting so I get access to some of the extra video modes. I'm running the latest (February 15th) firmware.
Recently I tried to startup Marinetti's Telnet program and I noticed it just seemed to hang. Same thing with Casper. After thinking about this for a bit, I switched the VidHD slot back to "Text Display" and Telnet works just fine.
Any idea what's going on here? Thanks!
- James
|
|
|
Re: VidHD Firmware Bug? [message #381702 is a reply to message #381701] |
Thu, 07 March 2019 17:25 |
|
Originally posted by: jbrooks
On Thursday, March 7, 2019 at 1:27:15 PM UTC-8, James Kruth wrote:
> I've been loving the VidHD, but I think I may have found a firmware bug. I've got the card in slot 3 of my ROM 3 IIgs and have been running with the "Your Card" setting so I get access to some of the extra video modes. I'm running the latest (February 15th) firmware.
>
> Recently I tried to startup Marinetti's Telnet program and I noticed it just seemed to hang. Same thing with Casper. After thinking about this for a bit, I switched the VidHD slot back to "Text Display" and Telnet works just fine.
>
> Any idea what's going on here? Thanks!
>
> - James
Hi James,
On the IIe and IIGS, it's probably best to keep Apple's slot 3 firmware active by default, and only swap in VidHD's firmware via POKE 49163,0 ($C00B:0) when you want to use extended text modes, etc.
The issue is that some parts of the Apple IIe and IIGS ROM code assume that the slot 3 text driver will be Apple's driver, that text memory will be located at $400-$7FF of main+aux memory, and that various internal firmware variables will be stored at specific locations in memory.
For example, the ROM INPUT routine always writes prompt and cursor characters into $400-$7FF, even when the COUT routine has been redirected to output characters via VidHD's slot 3 firmware instead of Apple's slot 3 firmware.
I've done some investigation into possible ways to bypass or work around these assumptions(bugs) in the ROM INPUT and GS Control Panel code, but don't have any solutions yet.
Since you are using a ROM3 IIGS, you can put VidHD in slot 1, 2, 4-6 which will let you use VidHD's firmware w/extended text modes without disabling Apple's slot 3 firmware which makes other parts of Apple's ROM code cranky.
Luckily, VidHD's firmware is now pretty easy to update, so I anticipate releasing new versions over time as I come up with improvements and workarounds.
-JB
twitter: @JBrooksBSI
|
|
|
Re: VidHD Firmware Bug? [message #381707 is a reply to message #381702] |
Thu, 07 March 2019 19:57 |
dawjazz
Messages: 10 Registered: February 2013
Karma: 0
|
Junior Member |
|
|
On Thursday, March 7, 2019 at 2:25:32 PM UTC-8, jbr...@blueshiftinc.com wrote:
> On Thursday, March 7, 2019 at 1:27:15 PM UTC-8, James Kruth wrote:
>> I've been loving the VidHD, but I think I may have found a firmware bug.. I've got the card in slot 3 of my ROM 3 IIgs and have been running with the "Your Card" setting so I get access to some of the extra video modes. I'm running the latest (February 15th) firmware.
>>
>> Recently I tried to startup Marinetti's Telnet program and I noticed it just seemed to hang. Same thing with Casper. After thinking about this for a bit, I switched the VidHD slot back to "Text Display" and Telnet works just fine.
>>
>> Any idea what's going on here? Thanks!
>>
>> - James
>
> Hi James,
>
> On the IIe and IIGS, it's probably best to keep Apple's slot 3 firmware active by default, and only swap in VidHD's firmware via POKE 49163,0 ($C00B:0) when you want to use extended text modes, etc.
>
> The issue is that some parts of the Apple IIe and IIGS ROM code assume that the slot 3 text driver will be Apple's driver, that text memory will be located at $400-$7FF of main+aux memory, and that various internal firmware variables will be stored at specific locations in memory.
>
> For example, the ROM INPUT routine always writes prompt and cursor characters into $400-$7FF, even when the COUT routine has been redirected to output characters via VidHD's slot 3 firmware instead of Apple's slot 3 firmware.
>
> I've done some investigation into possible ways to bypass or work around these assumptions(bugs) in the ROM INPUT and GS Control Panel code, but don't have any solutions yet.
>
> Since you are using a ROM3 IIGS, you can put VidHD in slot 1, 2, 4-6 which will let you use VidHD's firmware w/extended text modes without disabling Apple's slot 3 firmware which makes other parts of Apple's ROM code cranky..
>
> Luckily, VidHD's firmware is now pretty easy to update, so I anticipate releasing new versions over time as I come up with improvements and workarounds.
>
> -JB
> twitter: @JBrooksBSI
Excuse me for interjecting. I know your documentation states that the VidHD must reside in slot 3 in the ROM1 IIGS, but can it be put in one of the other slots? I want to use the TransWarp GS card in slot 3 and still keep the VidHD.
Thanks,
Dale Wilkins
|
|
|
Re: VidHD Firmware Bug? [message #381708 is a reply to message #381707] |
Thu, 07 March 2019 20:19 |
|
Originally posted by: jbrooks
On Thursday, March 7, 2019 at 4:57:06 PM UTC-8, dawjazz wrote:
> On Thursday, March 7, 2019 at 2:25:32 PM UTC-8, jbr...@blueshiftinc.com wrote:
>> On Thursday, March 7, 2019 at 1:27:15 PM UTC-8, James Kruth wrote:
>>> I've been loving the VidHD, but I think I may have found a firmware bug. I've got the card in slot 3 of my ROM 3 IIgs and have been running with the "Your Card" setting so I get access to some of the extra video modes. I'm running the latest (February 15th) firmware.
>>>
>>> Recently I tried to startup Marinetti's Telnet program and I noticed it just seemed to hang. Same thing with Casper. After thinking about this for a bit, I switched the VidHD slot back to "Text Display" and Telnet works just fine.
>>>
>>> Any idea what's going on here? Thanks!
>>>
>>> - James
>>
>> Hi James,
>>
>> On the IIe and IIGS, it's probably best to keep Apple's slot 3 firmware active by default, and only swap in VidHD's firmware via POKE 49163,0 ($C00B:0) when you want to use extended text modes, etc.
>>
>> The issue is that some parts of the Apple IIe and IIGS ROM code assume that the slot 3 text driver will be Apple's driver, that text memory will be located at $400-$7FF of main+aux memory, and that various internal firmware variables will be stored at specific locations in memory.
>>
>> For example, the ROM INPUT routine always writes prompt and cursor characters into $400-$7FF, even when the COUT routine has been redirected to output characters via VidHD's slot 3 firmware instead of Apple's slot 3 firmware.
>>
>> I've done some investigation into possible ways to bypass or work around these assumptions(bugs) in the ROM INPUT and GS Control Panel code, but don't have any solutions yet.
>>
>> Since you are using a ROM3 IIGS, you can put VidHD in slot 1, 2, 4-6 which will let you use VidHD's firmware w/extended text modes without disabling Apple's slot 3 firmware which makes other parts of Apple's ROM code cranky.
>>
>> Luckily, VidHD's firmware is now pretty easy to update, so I anticipate releasing new versions over time as I come up with improvements and workarounds.
>>
>> -JB
>> twitter: @JBrooksBSI
>
> Excuse me for interjecting. I know your documentation states that the VidHD must reside in slot 3 in the ROM1 IIGS, but can it be put in one of the other slots? I want to use the TransWarp GS card in slot 3 and still keep the VidHD.
>
> Thanks,
>
> Dale Wilkins
Hi Dale,
The GS has a special 'aux bank' line called M2B0 which only exists in slot 3 of ROM0/ROM1 motherboards. ROM3 motherboards have the M2B0 line in slots 1-6.
On a ROM1, if VidHD is not in slot 3, any write to aux 64K video memory will appear to VidHD to be a write to main 64K video memory. This can cause visual errors for 80-column text, double lores, double hires, and SHR video modes.
If you only run programs compatible with the Apple II, II+, IIe which access aux video memory by bank-switching them into main 64K, and do not run code with 65816 instructions that write into aux video memory in banks $01 or $E1, then VidHD will work in slots 1-6 of a ROM1 motherboard.
I recommend keeping VidHD in slot 3 and moving the Transwarp GS to slot 1 or 2 by rotating the CPU socket cable 180 degrees so it 'lays flat' instead of doubling back on itself. This is what I did with my Zip GS that was in slot 3. You can look at the Transwarp GS or Zip GS manual for info on using slots 1 or 2.
Hope that helps,
-JB
@JBrooksBSI
|
|
|
|
Re: VidHD Firmware Bug? [message #381719 is a reply to message #381713] |
Fri, 08 March 2019 00:33 |
|
Originally posted by: jbrooks
On Thursday, March 7, 2019 at 7:35:24 PM UTC-8, Wayne Stewart wrote:
> On the ROM 1 isn’t pin 35 only used on slots 3 and 7? If so why not solder a wire between that pin and the same on another slot?
The VidHD firmware ignores pin 35 on a ROM0/ROM1 when VidHD is not in slot 3 due to pin 35 being CREF in slot 7 or a no-connect in slots 1, 2, 4-6.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #381722 is a reply to message #381719] |
Fri, 08 March 2019 07:48 |
roughana
Messages: 219 Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Friday, March 8, 2019 at 4:33:34 PM UTC+11, jbr...@blueshiftinc.com wrote:
> On Thursday, March 7, 2019 at 7:35:24 PM UTC-8, Wayne Stewart wrote:
>> On the ROM 1 isn’t pin 35 only used on slots 3 and 7? If so why not solder a wire between that pin and the same on another slot?
>
> The VidHD firmware ignores pin 35 on a ROM0/ROM1 when VidHD is not in slot 3 due to pin 35 being CREF in slot 7 or a no-connect in slots 1, 2, 4-6.
>
> -JB
Here's a feature request for you: Add a config option to indicate to check that signal in a certain slot on ROM 00/01.
Other cards need that slot as well (e.g. VideoOverlay card, Visionary digitiser) so ROM 01 owners may have modified their systems to provide that signal to another slot.
Regards,
Andrew
|
|
|
Re: VidHD Firmware Bug? [message #381724 is a reply to message #381719] |
Fri, 08 March 2019 09:20 |
Charlie
Messages: 255 Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 3/8/2019 12:33 AM, jbrooks@blueshiftinc.com wrote:
> On Thursday, March 7, 2019 at 7:35:24 PM UTC-8, Wayne Stewart wrote:
>> On the ROM 1 isn’t pin 35 only used on slots 3 and 7? If so why not solder a wire between that pin and the same on another slot?
>
> The VidHD firmware ignores pin 35 on a ROM0/ROM1 when VidHD is not in slot 3 due to pin 35 being CREF in slot 7 or a no-connect in slots 1, 2, 4-6.
>
> -JB
>
I've been running my VidHD in slot 2 which has pin 35 connected to slot
3 via a soldered wire. This is a IIgs ROM 01.
I see no adverse screen effects.
Charlie
|
|
|
|
|
|
|
Re: VidHD Firmware Bug? [message #381758 is a reply to message #381702] |
Sat, 09 March 2019 15:54 |
|
Originally posted by: James Kruth
On Thursday, March 7, 2019 at 5:25:32 PM UTC-5, jbr...@blueshiftinc.com wrote:
> On the IIe and IIGS, it's probably best to keep Apple's slot 3 firmware active by default, and only swap in VidHD's firmware via POKE 49163,0 ($C00B:0) when you want to use extended text modes, etc.
That makes sense now that I think about it. I'm returning to Apple II stuff after a long hiatus and finding that there's a lot I don't remember.
If you don't mind some related questions - the slot 3 firmware is generally associated with the 80 column card, and in the IIe that comes from the aux card (if you have it). It looks like writing to $C00A turns on the ROM in slot 3, whereas writing to $C00B turns on the ROM in the aux slot? Correct?
Looking over the documentation it looks like neither Apple's various 80 column cards or the IIgs uses the I/O locations from $C0B0-$C0BF (slot 3). Would that mean those are still available to the card in the slot regardless of the setting in the control panel? Does the VidHD use any of the slot based I/O locations?
> The issue is that some parts of the Apple IIe and IIGS ROM code assume that the slot 3 text driver will be Apple's driver, that text memory will be located at $400-$7FF of main+aux memory, and that various internal firmware variables will be stored at specific locations in memory.
>
> For example, the ROM INPUT routine always writes prompt and cursor characters into $400-$7FF, even when the COUT routine has been redirected to output characters via VidHD's slot 3 firmware instead of Apple's slot 3 firmware.
>
> I've done some investigation into possible ways to bypass or work around these assumptions(bugs) in the ROM INPUT and GS Control Panel code, but don't have any solutions yet.
Do you have plans to (or have you already) open source the VidHD firmware? I'd be curious to learn more about how it works (especially the Linux portion).
> Since you are using a ROM3 IIGS, you can put VidHD in slot 1, 2, 4-6 which will let you use VidHD's firmware w/extended text modes without disabling Apple's slot 3 firmware which makes other parts of Apple's ROM code cranky..
I've considered that but I actually kind of like the ability to programmatically turn the ROM on and off, which I believe is unique to slot 3? Though given your notes about certain ROM routines working poorly, I wonder if I'll run into trouble.
> Luckily, VidHD's firmware is now pretty easy to update, so I anticipate releasing new versions over time as I come up with improvements and workarounds.
My first update went very smoothly - looking forward to future updates. Thanks for the fantastic hardware!
- James
|
|
|
Re: VidHD Firmware Bug? [message #381762 is a reply to message #381758] |
Sat, 09 March 2019 18:13 |
Christopher G. Mason
Messages: 156 Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 3/9/2019 3:54 PM, James Kruth wrote:
> If you don't mind some related questions - the slot 3 firmware is generally associated with the 80 column card, and in the IIe that comes from the aux card (if you have it). It looks like writing to $C00A turns on the ROM in slot 3, whereas writing to $C00B turns on the ROM in the aux slot? Correct?
>
> Looking over the documentation it looks like neither Apple's various 80 column cards or the IIgs uses the I/O locations from $C0B0-$C0BF (slot 3). Would that mean those are still available to the card in the slot regardless of the setting in the control panel? Does the VidHD use any of the slot based I/O locations?
You can use cards without ROMs on them in Slot 3 on the IIe and IIgs as
the I/O space remains free to use. The Uthernet cards are commonly
placed there.
|
|
|
Re: VidHD Firmware Bug? [message #381764 is a reply to message #381758] |
Sat, 09 March 2019 21:54 |
|
Originally posted by: jbrooks
On Saturday, March 9, 2019 at 12:54:39 PM UTC-8, James Kruth wrote:
> If you don't mind some related questions - the slot 3 firmware is generally associated with the 80 column card, and in the IIe that comes from the aux card (if you have it). It looks like writing to $C00A turns on the ROM in slot 3, whereas writing to $C00B turns on the ROM in the aux slot? Correct?
Correct. The C3ROM soft switches at $C00A/B exist on the //e, IIc, and GS. These machines also have CXROM switches at $C006/7 which will bank switch the entire $C100-$C7FF range between the slot card ROMs and motherboard ROM.
> Looking over the documentation it looks like neither Apple's various 80 column cards or the IIgs uses the I/O locations from $C0B0-$C0BF (slot 3).
3rd party video cards from Videx use the DevSel locations at $C0x0, but Apple's motherboard slot 3 firmware only uses the IoSel ROM at $C3xx plus parts of the CXROM at $C100-$CFFF.
> Would that mean those are still available to the card in the slot regardless of the setting in the control panel?
Yes, the DevSel I/O of slot cards can be accessed at $C0x0 even if the GS control panel is set to the built-in peripheral instead of "Your Card" for that slot. Slot 6 is special since the GS built-in 5.25 floppy controller has soft switches located at $C0Ex unless slot 6 is set to "Your Card".
The GS soft switch $C02D controls which slots are "Your Card" and which use the GS built-in peripheral.
> Does the VidHD use any of the slot based I/O locations?
Not really. The only use currently is that at power-on, VidHD's bus bridge chip reads the Apple ROM, identifies the machine type, and stores an ID byte at $C0xF. This is read later by the VidHD video daughter-card when it starts up and reads video memory and the beam position.
> Do you have plans to (or have you already) open source the VidHD firmware? I'd be curious to learn more about how it works (especially the Linux portion).
No open-source plans at the moment. What do you want to know about the linux portion?
VidHD does bare-metal control of the H5 SOC. Linux just initializes the hardware and loads the VidHD executable.
> I've considered that but I actually kind of like the ability to programmatically turn the ROM on and off, which I believe is unique to slot 3? Though given your notes about certain ROM routines working poorly, I wonder if I'll run into trouble.
On the GS, you can bank in/out Slot ROM's via $C02D, but putting VidHD in slot 3 is the only way to allow apps which use PR#3 or the AuxMove & AuxXer functions to take advantage of VidHD's extended resolution and fast DMA AuxMove.
> My first update went very smoothly - looking forward to future updates. Thanks for the fantastic hardware!
Thanks!
-JB
@JBrooksBSI
|
|
|
|
|
Re: VidHD Firmware Bug? [message #381801 is a reply to message #381766] |
Mon, 11 March 2019 03:46 |
|
Originally posted by: James Davis
On Saturday, March 9, 2019 at 8:18:24 PM UTC-8, dawjazz wrote:
> On Saturday, March 9, 2019 at 7:27:55 PM UTC-8, James Davis wrote:
>> On Saturday, March 9, 2019 at 2:54:42 AM UTC-8, Delfs wrote:
>>> https://www.callapple.org/vidhd/
>>
>> Call-A.P.P.L.E.'s "VidHD Manual 1.1 Feb 2019 – download PDF" is not working for me. Is it broken?
>>
>> "https://www.callapple.org/docs/vidhd/VidHD_Manual_1.1.pdf" gives an Error 404.
>
> As mentioned a few posts back, it's at https://www.callapple.org/vidhd/
That's Delfs' reply that I am referring to! The link there at Call-A.P.P.L..E., named, "VidHD Manual 1.1 Feb 2019 – download PDF" with target <"https://www.callapple.org/docs/vidhd/VidHD_Manual_1.1.pdf"> gives an Error 404 and so, it is not working for me. Is it working for anyone else? Is it broken? (I think this is also what Antoine Vignau is asking above.)
|
|
|
|
|
|
Re: VidHD Firmware Bug? [message #381926 is a reply to message #381764] |
Tue, 12 March 2019 23:12 |
|
Originally posted by: James Kruth
John,
Thanks for all your very detailed answers. I really appreciate it!
On Saturday, March 9, 2019 at 9:54:42 PM UTC-5, jbr...@blueshiftinc.com wrote:
>> Do you have plans to (or have you already) open source the VidHD firmware? I'd be curious to learn more about how it works (especially the Linux portion).
>
> No open-source plans at the moment. What do you want to know about the linux portion?
>
> VidHD does bare-metal control of the H5 SOC. Linux just initializes the hardware and loads the VidHD executable.
Partially I ask about open-source because I was thinking it would be a lot of fun to turn the black bars on either side of the VidHDs output into "blinkenlights". I figure at any given time the VidHD knows a fair amount of what's going on inside the Apple II it's running in. Some status outputs might be fun/useful. I had also wondered about taking over the display entirely and just displaying bus status.
I also was very curious about what techniques you used to get linux to boot so quickly. I'm impressed at the speed which the VidHD comes up.
- James
|
|
|
Re: VidHD Firmware Bug? [message #381930 is a reply to message #381926] |
Tue, 12 March 2019 23:33 |
|
Originally posted by: jbrooks
On Tuesday, March 12, 2019 at 8:12:18 PM UTC-7, James Kruth wrote:
> Thanks for all your very detailed answers. I really appreciate it!
I'm happy to help, and welcome VidHD questions & requests.
> Partially I ask about open-source because I was thinking it would be a lot of fun to turn the black bars on either side of the VidHDs output into "blinkenlights". I figure at any given time the VidHD knows a fair amount of what's going on inside the Apple II it's running in. Some status outputs might be fun/useful. I had also wondered about taking over the display entirely and just displaying bus status.
I too have thought about adding some fun dev/geek modes, but fixing bugs and compatibility issues has taken precedence. I'd also like to make it possible for people to run their own code on the VidHD ARM64, but the 1,020,484 frames-per-second requirement needed to keep up with the 1MHz 6502 makes the system rather tricky and inflexible.
> I also was very curious about what techniques you used to get linux to boot so quickly. I'm impressed at the speed which the VidHD comes up.
The main speed-up was to use buildroot to create a custom embedded linux distro that has all the device drivers compiled into the linux kernel, and to embed the root filesystem into the kernel as a ramdisk image. That way the whole linux system loads in one big chunk at boot and skips all of Linux's hardware probing and module loading overhead.
Buildroot (https://buildroot.org/) does most of the magic automatically, so having a fast-booting linux is accessible to anyone who has the fortitude to wade through the docs/options/trials.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #381940 is a reply to message #381930] |
Wed, 13 March 2019 08:46 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi John,
> I'd also like to make it possi=
> ble for people to run their own code on the VidHD ARM64, but the 1,020,484 =
> frames-per-second requirement needed to keep up with the 1MHz 6502 makes th=
> e system rather tricky and inflexible.
Is that requirement still in place if the code in question doesn't
intend to "capture" all 6502 bus accesses tranparently anymore? I'm
thinking about a scenario where VidHD acts more like a traditional A2
slot card. The 6502 writes to let's say $C800-$CFFF. It requires
several cycles before the next write. One could even add NOPs to slow
things down. Would such a scenario make programming the VidHD ARM64
simpler? Or is that requirement rather based on 6502 bus timings?
Regards,
Oliver
|
|
|
Re: VidHD Firmware Bug? [message #381950 is a reply to message #381940] |
Wed, 13 March 2019 12:50 |
|
Originally posted by: jbrooks
On Wednesday, March 13, 2019 at 5:46:20 AM UTC-7, Oliver Schmidt wrote:
> Hi John,
>
>> I'd also like to make it possi=
>> ble for people to run their own code on the VidHD ARM64, but the 1,020,484 =
>> frames-per-second requirement needed to keep up with the 1MHz 6502 makes th=
>> e system rather tricky and inflexible.
>
> Is that requirement still in place if the code in question doesn't
> intend to "capture" all 6502 bus accesses tranparently anymore? I'm
> thinking about a scenario where VidHD acts more like a traditional A2
> slot card. The 6502 writes to let's say $C800-$CFFF. It requires
> several cycles before the next write. One could even add NOPs to slow
> things down. Would such a scenario make programming the VidHD ARM64
> simpler? Or is that requirement rather based on 6502 bus timings?
The ARM64 must capture all 6502 bus accesses in order to reliably detect when the 6502 does a write to $C800 etc.
Capturing is easy and fast for the ARM64. The problem is making sure that any processing of those captured cycles doesn't take so much time that later cycles are missed.
ARM64 stalls due to cache/DRAM, linux thread scheduling, file I/O, etc. can make processing take too long and cause the loss of subsequent bus cycles.
As you mention, adding nops after a write or using other sync methods can relax the 980ns timing constraint, but the hard-realtime nature of the 6502 bus means that processing code is likely to be inflexible.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #381951 is a reply to message #381950] |
Wed, 13 March 2019 13:02 |
|
Originally posted by: fadden
On Wednesday, March 13, 2019 at 9:50:40 AM UTC-7, jbr...@blueshiftinc.com wrote:
> ARM64 stalls due to cache/DRAM, linux thread scheduling, file I/O, etc. can make processing take too long and cause the loss of subsequent bus cycles.
Are you using SCHED_FIFO or SCHED_RR?
That, performing file I/O off thread, and avoiding locks on the main work thread should yield reasonable results under Linux.
|
|
|
|
Re: VidHD Firmware Bug? [message #381963 is a reply to message #381951] |
Wed, 13 March 2019 18:38 |
|
Originally posted by: jbrooks
On Wednesday, March 13, 2019 at 10:02:57 AM UTC-7, fadden wrote:
> On Wednesday, March 13, 2019 at 9:50:40 AM UTC-7, jbr...@blueshiftinc.com wrote:
>> ARM64 stalls due to cache/DRAM, linux thread scheduling, file I/O, etc. can make processing take too long and cause the loss of subsequent bus cycles.
>
> Are you using SCHED_FIFO or SCHED_RR?
>
> That, performing file I/O off thread, and avoiding locks on the main work thread should yield reasonable results under Linux.
I tried various scheduler settings, but they didn't help. I eventually discovered that hardware DMAs initiated by linux drivers could hog the AMBA bus and cause the VidHD thread to miss 6502 cycles.
VidHD uses a four strategies to avoid missing bus cycles:
1) Apple II bus data from the ARM32 bridge chip is DMAd into a ring buffer in SOC SRAM using 'highest priority' DMA channels that preempt any DMA operations performed by linux
2) The linux kernel is compiled to use the server scheduler (co-op instead of preemptive scheduling), and the VidHD thread is scheduled w/affinity to run on an unused ARM64 core
3) The VidHD thread tracks Apple II bus state as its top priority so that Apple II main/aux bank switching events, video mode changes, or writes to vram will take precedence over drawing pixels to the 1080p frame buffer
4) Pixel data being written to the 1080p frame buffer is timed/pipelined so that it doesn't stall the AMBA bus and the DMA channel writing Apple II bus cycle data to SRAM.
To minimize linux-related stalls, VidHD is coded to have no dynamic memory allocations, it runs as a single thread on one core, and it does no file I/O.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #382079 is a reply to message #381963] |
Sat, 16 March 2019 12:02 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi John,
> VidHD uses a four strategies to avoid missing bus cycles:
>
> [...]
Linux is said to be not well suited for hard real-time requirements.
What you write seems to support that perspective. Therefore my -
hopfully not too stupid - question: Why Linux?
People usually use Linux because they want to re-use some Linux code
or some code relying on Linux. Things like SAMBA, CUPS, <...>
VidHD seems to require "only" a somewhat beefy processor and HDMI
output. Am I naive to believe that those two can be found without
implying Linux? Likely I'm missing some general point...
Regards,
Oliver
|
|
|
Re: VidHD Firmware Bug? [message #382083 is a reply to message #382079] |
Sat, 16 March 2019 13:24 |
|
Originally posted by: fadden
On Saturday, March 16, 2019 at 9:02:08 AM UTC-7, Oliver Schmidt wrote:
> People usually use Linux because they want to re-use some Linux code
> or some code relying on Linux. Things like SAMBA, CUPS, <...>
Interrupt management, DMA, system bootstrap, executable object loading, virtual memory management, OEM device drivers, ...
To avoid Linux you'd want to find an alternative OS that is free/cheap, supports ARM64, has developer tools that are free/cheap, is well documented, and ideally has manufacturer-maintained drivers for whatever devices you're planning to drive. Otherwise you're writing your own OS, which is bound to be more time and trouble than figuring out how to work around the undesirable parts of Linux.
Android uses the Linux kernel, but abandoned most of the user-facing stuff (SAMBA, CUPS, ...). Even glibc got replaced. There's huge value in the Linux kernel for embedded systems.
In a previous job we used the thread affinity approach to get low latency out of a system that was driving AR glasses over USB. For some reason I assumed the VidHD used a single-core CPU, but maybe that's just not a thing anymore. :-) We were running on full Android, which was bad (*lots* of stuff going on in the system) but also good (systrace lets you see exactly what's going on where). Our latency requirements were a bit more generous than 980ns though. :-)
|
|
|
Re: VidHD Firmware Bug? [message #382095 is a reply to message #382079] |
Sat, 16 March 2019 14:16 |
|
Originally posted by: jbrooks
On Saturday, March 16, 2019 at 9:02:08 AM UTC-7, Oliver Schmidt wrote:
> Linux is said to be not well suited for hard real-time requirements.
> What you write seems to support that perspective. Therefore my -
> hopfully not too stupid - question: Why Linux?
To develop software for the H5 ARM64 processor, my choices were Linux or Android, with Android using an older rev of linux & drivers.
Mainline Linux allowed me to use the latest drivers, use wifi to ssh into the ARM64 video board, compile, debug, transfer files easily, and generally have access to a mainstream development workflow.
For deployment, I considered making VidHD execute directly from the uboot loader and not use linux, but the complexity of the H5 video driver and probing/configuring the incredible variety of HDMI displays pushed me to use the full linux kernel.
Other benefits of using linux:
1) Micro-SD card drivers for firmware updates
2) Linux shell scripting & performance monitoring tools
3) Drivers for possible use of wifi & usb in the future
4) Virtual memory for possible use in the future
> For some reason I assumed the VidHD used a single-core CPU, but maybe that's just not a thing anymore. :-)
I was initially planning to use linux in single-core mode to reduce power consumption, but the H5 BSP didn't support a single-core config. While VidHD only utilizes one core, keeping the linux threads off the VidHD core was good for performance.
-JB
|
|
|
|
Re: VidHD Firmware Bug? [message #382098 is a reply to message #382083] |
Sat, 16 March 2019 14:47 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
> Interrupt management, DMA, system bootstrap, executable object loading, vir=
> tual memory management, OEM device drivers, ...
All this is necessary to support an OS. VidHD doesn't need any of
these.
> To avoid Linux you'd want to find an alternative OS that is [...]
No, I'd want to go without an OS.
Regards,
Oliver
|
|
|
Re: VidHD Firmware Bug? [message #382099 is a reply to message #382095] |
Sat, 16 March 2019 15:07 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi John,
> To develop software for the H5 ARM64 processor, my choices were Linux or Android, with Android using an older rev of linux & drivers.
I see people doing "bare metal on the RPi3" so I thought that would
have been an option for the H5 ARM64 too.
> Mainline Linux allowed me to use the latest drivers, use wifi to ssh into the ARM64 video board, compile, debug, transfer files easily, and generally have access to a mainstream development workflow.
I see. Not primary product features, but development features. I was
only wondering if those benefits outweight the difficulties you wrote
about.
> For deployment, I considered making VidHD execute directly from the uboot loader and not use linux, [...]
That's the sort of approach my question was heading to.
> [...] but the complexity of the H5 video driver and probing/configuring the incredible variety of HDMI displays pushed me to use the full linux kernel.
Yeah, I read your recent posts on an updated Linux HDMI driver
(hopefully) supporting more displays. From that perspective it all
makes sense. I likely totally underestimated the complexity of HDMI -
and how much of it is software (not hardware).
> Other benefits of using linux:
> 1) Micro-SD card drivers for firmware updates
SPI-based Micro-SD card access (incl. FAT32 support) seems to be
available in many forms for bare metal.
> 2) Linux shell scripting & performance monitoring tools
I see.
> 3) Drivers for possible use of wifi & usb in the future
For sure. I was thinking about the current VidHD and wondering how
likely it is that those features can be actually used given the
complexity you described to meet the real-time requirements.
> 4) Virtual memory for possible use in the future
Isn't any paging supposed to break the real-time requirements you
described for sure?
Anyhow, I understood that HDMI output with a high level of
compatibility with many different displays asks for the Linux HDMI
driver - and that compatibility is a (or even the) core feature of
VidHD. So my original question is fully answered.
Thanks for your explanation,
Oliver
|
|
|
Re: VidHD Firmware Bug? [message #382116 is a reply to message #382096] |
Sat, 16 March 2019 20:09 |
|
Originally posted by: jbrooks
On Saturday, March 16, 2019 at 11:33:23 AM UTC-7, Steven Hirsch wrote:
> Not a bug, but more my curiosity: What is the probe-like component clipped to
> the card? Is that an antenna of some sort?
It's a WIFI + Bluetooth antenna.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #382119 is a reply to message #382099] |
Sat, 16 March 2019 20:40 |
|
Originally posted by: jbrooks
On Saturday, March 16, 2019 at 12:07:45 PM UTC-7, Oliver Schmidt wrote:
>
> I see people doing "bare metal on the RPi3" so I thought that would
> have been an option for the H5 ARM64 too.
Yes, it should be possible, but I do not know of anyone doing bare-metal programming of the H5 yet. The H5 is a much newer SOC than what the RPI uses, with a lot less documentation or community support. Many of the H5 drivers are still incomplete:
http://linux-sunxi.org/Linux_mainlining_effort
>> Mainline Linux allowed me to use the latest drivers, use wifi to ssh into the ARM64 video board, compile, debug, transfer files easily, and generally have access to a mainstream development workflow.
>
> I see. Not primary product features, but development features. I was
> only wondering if those benefits outweight the difficulties you wrote
> about.
VidHD does its own H5 bare-metal control of DMA, I/O with the ARM32, and SRAM & frame buffer memory. The crucial linux driver I didn't want to recreate was all the HDMI probe & configure logic.
> Yeah, I read your recent posts on an updated Linux HDMI driver
> (hopefully) supporting more displays. From that perspective it all
> makes sense. I likely totally underestimated the complexity of HDMI -
> and how much of it is software (not hardware).
Me too! :)
>> 3) Drivers for possible use of wifi & usb in the future
>
> For sure. I was thinking about the current VidHD and wondering how
> likely it is that those features can be actually used given the
> complexity you described to meet the real-time requirements.
It should be possible, but would take a fair amount of development & testing. I think the easiest use would be short-burst networking done while in the VidHD control panel to do things like upload screen shots, download a firmware update, etc.
>> 4) Virtual memory for possible use in the future
>
> Isn't any paging supposed to break the real-time requirements you
> described for sure?
As long as the Apple II CPU is running VidHD's Cs00 driver, or the VidHD control panel is active, the ARM64 code can run without real-time requirements.
-JB
|
|
|
Re: VidHD Firmware Bug? [message #382124 is a reply to message #382119] |
Sun, 17 March 2019 04:47 |
ol.sc
Messages: 211 Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi John,
> VidHD does its own H5 bare-metal control of DMA, I/O with the ARM32, and SRAM & frame buffer memory. The crucial linux driver I didn't want to recreate was all the HDMI probe & configure logic.
Thanks for that background info!
>> For sure. I was thinking about the current VidHD and wondering how
>> likely it is that those features can be actually used given the
>> complexity you described to meet the real-time requirements.
>
> It should be possible, but would take a fair amount of development & testing. I think the easiest use would be short-burst networking done while in the VidHD control panel to do things like upload screen shots, download a firmware update, etc.
I see.
>>> 4) Virtual memory for possible use in the future
>>
>> Isn't any paging supposed to break the real-time requirements you
>> described for sure?
>
> As long as the Apple II CPU is running VidHD's Cs00 driver, or the VidHD control panel is active, the ARM64 code can run without real-time requirements.
I see.
Thanks, Oliver
|
|
|
Re: VidHD Firmware Bug? [message #382266 is a reply to message #382124] |
Thu, 21 March 2019 01:21 |
|
Originally posted by: James Kruth
John,
One other question that's somewhat related: sometimes it seems my VidHD fails to initialize properly, or something... I'm not sure what. I am getting composite output, just not output from the VidHD. Is there any kind of log file or diagnostic code that would tell me what's going on?
- James
|
|
|
Re: VidHD Firmware Bug? [message #382381 is a reply to message #382266] |
Sat, 23 March 2019 22:26 |
|
Originally posted by: jbrooks
On Wednesday, March 20, 2019 at 10:22:00 PM UTC-7, James Kruth wrote:
> John,
>
> One other question that's somewhat related: sometimes it seems my VidHD fails to initialize properly, or something... I'm not sure what. I am getting composite output, just not output from the VidHD. Is there any kind of log file or diagnostic code that would tell me what's going on?
>
> - James
You can see if the VidHD linux OS is booting by looking for a red and green LED to come on at the back of the daughter-card a few seconds after the Apple II is powered on. The LEDs are located behind VidHD's micro-SD card slot.
If the LEDs don't turn on, then linux is failing to boot from the onboard flash memory. Try booting firmware 1.15 from a micro-SD card since the SD boot requires less power.
-JB
|
|
|