• Please review our updated Terms and Rules here

Unknown 1802-Based System

Regarding those call and return routines, were you aware of the convention used at The Labs?
 
The keyboard was ordered from a Electronic Parts Surplus Magazine, I ordered them for the other Students.

Interesting. So, I guessed right about the keyboard being purchased from a surplus parts company.

I think it's amazing that @NeXT has his answers direct from someone so close to the actual builder, less than a year and a half after he first posted about this. This is an example of how small the world is in the 21st century.

@GeSnow: How did you stumble upon this thread in the first place?
 
I found this when I searched for 1802 Computers in YouTube, then I found the video, and noticed that is was one of the few Project 1802 PCs we built at VanTech. I was thinking that it might be worth converting the keyboard interface to use a raspbery pi pico and using a standard USB keyboard. I will very likely need to rewrite some of the bios on this system. I plan to document the code, we worked on this back in 1983, that was a long time ago.

On my system I also added another CPD1852 for a joystick interface, that was very easy to do.
 
I think it's amazing that @NeXT has his answers direct from someone so close to the actual builder, less than a year and a half after he first posted about this. This is an example of how small the world is in the 21st century.
I'm very thankful as well. Small projects and assignments like this have pretty much been lost to time through garage sales, 1-800-got-junk or natural disasters and at the same time they are so different from the usual hobbyist projects (remember that this has very little in common design shared with the membership card, the ELF, the COMX or the VIP) that tend to follow the same design that you really want to find out more. I love computers like this. I have no problem posting photos of them when I find them. and yeah if you have extra peripherals you added photos are invaluable because the boards are so simple.
 
I was thinking that it might be worth converting the keyboard interface to use a raspbery pi pico and using a standard USB keyboard.

I would think that creating a pico interface that mimics the Vydec keyboard matrix would be a nice way to keep the original design intact while still providing the upgrade. You could even leave the original keyboard connected and in place and just have a USB port sticking out of the case. This would give you the best of both worlds and leave your original work mainly untouched.

I will very likely need to rewrite some of the bios on this system. I plan to document the code, we worked on this back in 1983, that was a long time ago.

If you use the above idea, you wouldn't have to rewrite any of the BIOS. Or you might instead add to the BIOS for any keys unique to the USB keyboard. But I'd make the pico do the work. Maybe even add key macroing capabilities for the USB keyboard.

Do you still have the original BIOS source you converted into hex codes?
 
Very interesting :)

I managed to add some emulation for this DIY machine via my new XML (beta) feature in Emma 02. Video and keyboard are working; will try the load/save tomorrow.
 

Attachments

  • screendump.png
    screendump.png
    539 bytes · Views: 9
Very interesting :)

I managed to add some emulation for this DIY machine via my new XML (beta) feature in Emma 02.

Do you think you'll be able to produce a complete emulation without ever coming in contact with the real hardware?

If you can, that would be great.
 
I don’t necessarily need the real HW but would need specs or schematics to make it ‘complete’. Of all the machines that I currently have emulated in Emma 02 I only have real HW for 2 of them (COMX and VIP2K). I don’t claim they are all perfect or fault free 🤪.

For the Macbug, I already made guesses for the video; but all guesses are in an xml file so can easily be changed. The keyboard emulation is based on a generic matrix type keyboard emulation code used for the Pecom. For the ROM code that works but it is not (or far from) 100%; for now good enough but if needed I can make it more ‘correct’.

Cheers, Marcel
 
With some shortcuts I got load/save running very quickly... the ROM is using the 'standard' 1802 save option with Q/EF for save/load.

There are some things that I don't understand:
1. At start of SAVE an OUT 1 with 0x53 is done followed by two OUT 1s with 0. Same on LOAD but then the first OUT 1 is with 0x4C. It also loops waiting for EF2 before it starts. Maybe EF2 is indicating that the tape is playing, recording or stopped depending on the OUT 1 value? Just a guess.
2. Besides the tape I/O with Q/EF I also get all bytes outputted via OUT 4 both on LOAD and SAVE. No idea why that is done. There were no TIL displays anywhere in this machine, right?

If anyone would like an Emma 02 beta build with Macbug support, just let me know what OS you use (win32, win64, win arm, macOS, linux) and I'll provide a download link. Note that it might take some days to create, especially linux could take a while... so far I have only tested on macOS.

Attached are some LOAD/SAVE screenshots.

Cheers, Marcel.
 

Attachments

  • loading.png
    loading.png
    1.5 KB · Views: 9
  • saving.png
    saving.png
    1.3 KB · Views: 8
Last edited:
I looked a bit more at the tape routines and the OUT 1. It looks like the 0x53 is the L key (LOAD) and 0x4C the S (SAVE), why that would be send to the OUT 1 I don't understand. It is also done just before 'NAME?' is printed and after the first character is received from the keyboard the OUT 1 with 0 is done. So it doesn't really link with the LOAD or SAVE start itself.

I did add some logic to have EF2 indicate if the tape is running that works nicely.

For the video, a guess I made is that the 0x01 which is put (at startup) on 0xD8FC is to set the MC6847 function, like graphic mode etc. Question is which bits are used where, and of course if my guess is correct. For this I would need some mode detailed specs or schematics. I'll have a look at the pictures to see if I can figure something out. Either way as mentioned any of this can be changed in the xml file.

I had also assumed that b7 of the character byte is to inverse the character. This as it was used like that on another 1802 implementation with the MC6847. This could also be a graphic mode, the CSS color bit or something else. Same for b6 which I initially linked to EXT font ROM but this corrupted the screen, so I just removed it.

If anyone has any details on any of this or if anyone is able to try some key presses on the real machine which are NOT A-Z or 1-0; maybe SHIFT A-Z or CTRL A-Z and give some hints if that shows up some graphic characters, inverted or different colors it would be much appreciated.
 
Last edited:
Hmm, looking at the picture NeXT posted with the small color TV it looks like the screen is showing inverted characters. That could indicate that the 0x01 on 0xD8FC, if used for MC6847 functions, has bit 0 connected to the INV. Like first attached screenshot below.

Then bit 7 of the character byte itself could be A/S for semigraphics, like second screenshot?
Or bit 7 is for color but that looks strange, so I guess not, see third screenshot.
 

Attachments

  • inv.png
    inv.png
    943 bytes · Views: 4
  • graphics.png
    graphics.png
    1 KB · Views: 4
  • color.png
    color.png
    1.1 KB · Views: 4
Back
Top