retrohimpi
Member
My first home computer, way back in 1979, was an Ohio Scientific Inc (OSI) Challenger 1P (a SuperBoard in a metal case with 1Mhz 6502, 8Kb RAM, PSU and TV modulator) and I'm currently trying to emulate it in Java. As usual, I had no idea how hard all this was going to be when I started, or I'd never have begun 
Although the architecture and much of the code is my own, I've shamelessly cribbed ideas, algorithms, manuals, data sheets, ROMs and disk images from various sources on the net and ported portions of published code written in C, C++ and JavaScript. So far, I have an XML-driven system for generating arbitrary 8-bit CPU emulators with a working NMOS 6502 example, and a more-or-less functional hardware emulation of my original cassette-based OSI system. I think there may still be a few bugs in the CPU, as it's hard to be sure that it always faithfully follows the specs and quirks of the original. It runs the original primitive ROM monitor and BASIC in ROM and can save/load BASIC or hex at 300 baud to/from text files on the host system's hard disk.
Now I'm trying to add the hardware I couldn't afford back in the early 80s, and give my emulation a RAM expansion to 48Kb plus twin 5.25" floppy drives, based on the OSI 610 expansion card, to produce the equivalent of a C1P MF (mini floppy) system. It appears to boot from an OS65D disk image, but then hangs without printing anything to its screen. When I break in via my front panel controls it is always stuck in its serial output driver routines, and I suspect that it's not recognising its built-in keyboard and screen and is trying to use a TTY via a non-existent serial port instead. However, it's hard to tell exactly when/how it detects the available hardware and I'm still debugging the boot code and my expansion card emulation. It may be that I have to emulate more I/O ports, or tweak the existing code to signal what, if anything, is on the other end of each line, or possibly that the original circuitry gave some non-obvious response when accessing memory addresses that weren't decoded.
If anyone knows what should appear on the screen during/after booting, that would be a great help as all I get at the moment is a screen clear after I respond to the initial D/C/W/M? monitor prompt and then a lot of activity from the disk drive as it loads DOS, BASIC, the disk catalog track and then BEXEC* (its BASIC equivalent of "autoexec.bat", which looks as though it should display a menu of options). I'm booting from a C1P OS65D v3.3 Tutorial 5 disk image, which appears to be the nearest it had to a system disk. Another possible problem is that the disk images I have look as if they may contain a few bad sectors (OS65V doesn't use any kind of checksum, as far as I can tell), as I can see some suspicious-looking $FF and $FE bytes in the middle of ASCII text strings when I dump the tracks individually. OSI rolled their own disk controllers so the original floppy disks, even if I had them, aren't compatible with other drives.
I hope to post some screen shots soon.
Although the architecture and much of the code is my own, I've shamelessly cribbed ideas, algorithms, manuals, data sheets, ROMs and disk images from various sources on the net and ported portions of published code written in C, C++ and JavaScript. So far, I have an XML-driven system for generating arbitrary 8-bit CPU emulators with a working NMOS 6502 example, and a more-or-less functional hardware emulation of my original cassette-based OSI system. I think there may still be a few bugs in the CPU, as it's hard to be sure that it always faithfully follows the specs and quirks of the original. It runs the original primitive ROM monitor and BASIC in ROM and can save/load BASIC or hex at 300 baud to/from text files on the host system's hard disk.
Now I'm trying to add the hardware I couldn't afford back in the early 80s, and give my emulation a RAM expansion to 48Kb plus twin 5.25" floppy drives, based on the OSI 610 expansion card, to produce the equivalent of a C1P MF (mini floppy) system. It appears to boot from an OS65D disk image, but then hangs without printing anything to its screen. When I break in via my front panel controls it is always stuck in its serial output driver routines, and I suspect that it's not recognising its built-in keyboard and screen and is trying to use a TTY via a non-existent serial port instead. However, it's hard to tell exactly when/how it detects the available hardware and I'm still debugging the boot code and my expansion card emulation. It may be that I have to emulate more I/O ports, or tweak the existing code to signal what, if anything, is on the other end of each line, or possibly that the original circuitry gave some non-obvious response when accessing memory addresses that weren't decoded.
If anyone knows what should appear on the screen during/after booting, that would be a great help as all I get at the moment is a screen clear after I respond to the initial D/C/W/M? monitor prompt and then a lot of activity from the disk drive as it loads DOS, BASIC, the disk catalog track and then BEXEC* (its BASIC equivalent of "autoexec.bat", which looks as though it should display a menu of options). I'm booting from a C1P OS65D v3.3 Tutorial 5 disk image, which appears to be the nearest it had to a system disk. Another possible problem is that the disk images I have look as if they may contain a few bad sectors (OS65V doesn't use any kind of checksum, as far as I can tell), as I can see some suspicious-looking $FF and $FE bytes in the middle of ASCII text strings when I dump the tracks individually. OSI rolled their own disk controllers so the original floppy disks, even if I had them, aren't compatible with other drives.
I hope to post some screen shots soon.