Programming HBIOS Visual Display Adapter driver

88 views
Skip to first unread message

Alastair Patrick

unread,
May 28, 2022, 10:40:39 PM5/28/22
to retro-comp
I have the beginnings of a VDA driver for my Pico-VDP board.  The source code is here. It's somewhat working. I've tested most of my implementations of the HBIOS VDA interface.  I have a test program that echoes what I type on a USB keyboard to a VGA monitor.

At the moment I'm hacking on it using SCM Monitor 1.3.0, which is working out well. The debugging support in SCM has been a lifesaver getting things going. I haven't taken the step of integrating my driver with RomWBW yet.

Does anyone have tips? I'm particularly looking for advice on process and minimizing build-deploy-debug iteration period. For example, the worst possible iteration I can think of is burning a ROM with new code, plugging it back into my SC126 and rebooting. With the number of iterations I need to get anything useful done, I'd wear out the chip and socket!

Better would be writing new data to an SD card, ideally without transferring the SD card between computers, and then booting RomWBW from that card.

What's the best way? I'm not even sure what's possible. In fact. this is the first software I've written for RomWBW and maybe starting with a VDA driver is trial by fire?!

I have am SC126, an SD card adapter, SC cards, an FTDI serial adapter. I do not have an EPROM programmer but would buy one if necessary.

Thanks!

Al

Tom Storey

unread,
May 30, 2022, 12:22:22 PM5/30/22
to Alastair Patrick, retro-comp
Quickest way I know is to transfer over via serial. If you can somehow load a new HBIOS into RAM and have it execute from there instead of ROM, or figure out how to swap RAM into the area where ROM usually would be, then the time required to test a new version of it is as long as it takes to push a reset button and reload the code via serial.

I use my own bootloader which implements a simple binary protocol like "load the following data starting at address x" or "jump to address y". Very simple, very dumb, but it works and I find it to be the quickest way to test and develop, especially when you need to iterate very rapidly.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/ddaa3864-8afd-4ae6-b65f-014b8339f423n%40googlegroups.com.

Wayne Warthen

unread,
May 30, 2022, 12:31:29 PM5/30/22
to retro-comp
Yes, RomWBW produces multiple output when you build a ROM.  The main output is the .rom file which is intended to be programmed to your EEPROM.  However, there will also be a .com file.  This file can be uploaded and launched under CP/M.  It will overlay the current HBIOS and restart the system as though it was the actual ROM contents.

Thanks,

Wayne

Alastair Patrick

unread,
May 30, 2022, 3:28:36 PM5/30/22
to retro-comp
Thanks Wayne, that's brilliant. I knew I could program a ROM or an SD card with an image but didn't realize what the COM files were for. I suppose it should have been obvious from the file extension! I have that process working now.

Al

Wayne Warthen

unread,
May 30, 2022, 3:30:20 PM5/30/22
to retro-comp
Yeah.  Avoiding the "burn" cycle for each test run is almost mandatory during development.
Reply all
Reply to author
Forward
0 new messages