DanBoris

I am guessing you found the ones I drew a long time ago. I believe I did them in ORCAD and stopped maintaining them when I no longer had access to a working copy of that program. I had always intended to re-draw them but never got around to it. Thanks for the work brining them into a more modern schematics capture tool.

Keep in mind, the 8048 has the O2 BIOS ROM programmed into it, so if you buy an off-the-shelf 8048 you will need a way to program it.

A6 also could be shorted to some other random signal instead of another address like.

It looks like a reset but it's definitely executing that data as if it was code. If you disassemble 0000 you get: 0000: 83E0 0012 C @>0012,R15 0004: 83C0 C R0,R15 From your trace: 0000: 83E0 C (compare) opcode 0002: 0012 compare operand 0012: Read value at 0012 83FE: Read R15 0004: 83C0 C (compare) opcode 83E0: Read R0 83FE: Read R15 So it looks like bit 0080 is not going high when it is supposed to. There are other reads where it is high so it's not being pulled to ground all the time.

Could it be that the 0080 bit and 0200 bit are reversed on the logic analyzer? If they were, then you would see this behavior if the 0080 signal is not making it to the ROM.

Looking at the reads starting at 200, it is definitely executing the data at 0000 as if it was opcodes.

See next post...

0200 83E0 0202 0012 0204 83C0 0206 0A4C 0208 83C0 If I assume these values are reads, that is not what is at location 200-208 in the ROMS I am using, but this is exactly what is at addresses 0000-0008

I know limi set the interrupt mask register, but is 0070: limi >0002 enabling or disabling interrupts?

200 is not an interrupt handler in the version of the ROM I am running. In the logic analyzer dump I would also expect to see a read from the IRQ vector at 0004, although maybe this is something the logic analyzer missed. Does seem to be the most logical explanation of how it suddenly gets to 0200.

I tried matching the logic analyzer dump to the trace I did and some of it matches but then goes off the rails FFFE 0000 0000 83FE 83FA 83FA 0002 0012 83FA 0016 83E0 001A 0034 83FA 9800 83E8 0036 83E0 83EC 0038 0060 83EC 83FA 0062 9C02 0064 0066 83EC 83FA 0068 9C02 006A 006C 0046 006E 837C 0070 0072 0076 0079 83FA DE00 83F2 007A 007C 83F2 83E8 83E8 0200 0202 0012 83FE 0204 83E0 03FE 0206 03F8 83F8 0208 83E0 83FE 020A 83E4 83E4 020C 83F4 0000: 83E0 ;Initial WP 0002: 0012 ;Reset vector ;0002 0012: li R13,>9800 ;0012, 83FA 0016: li R0,>0020 ;0016, 83E0 001A: jmp >0034 ;001A 0034: movb *R13,R4 ;0034, 83FA, 9800, 83E8 0036: mov R0,R6 ;0036, 83E0 83EC 0038: jmp >0060 ;0038 0060: movb R6,@>0402(R13) ;0060 83EC 83FA 0062 9C02 0064: movb @>83ed,@>0402(R13) ;0064 0066 83EC 83FA 0068 9C02 006A: szcb @>0047,@>837c ;006A 006C 0046 006E 837C 0070: limi >0002 ;0070 0072 Up to this point everything looks good, but then the next address is 0076. If that was an opcode read it would be reading 0000 which is an illegal opcode. The next read is then 0079 which I assume can't be an opcode read since it's not an even address. I guess there could be a difference in the ROM. 0074: limi >0000 0078: movb *R13,R9 Here is get's back on track 007A: jlt >0086 ;007A 007C: movb R9,R4 ;007C 83F2 83E8 83E8 then somehow we end up at 200. This is not an exact match, looks like the same code but different registers . 0200: D7E0 83E7 movb @>83e7,*R15 ;0200 0202 0012 83FE 0204: 0263 4000 ori R3,>4000 ;0204 83E0 03FE 0206 03F8 83F8 0208: D7C3 movb R3,*R15 ;0208 83E0 83FE 020A: D145 movb R5,R5 ;020A 83E4 83E4 020C: 1303 jeq >0214 ;020C 83F4

If it helps any, I ran a trace of the boot process using the debugger on MAME/MESS. This is from a TI99/4 but I am not sure if there are different versions of the BIOS rom which might lead to it not being an exact match. ti994.zip

I remember the SALT diagnostics from back in the day, but I never knew about this device. I just wrote a blog post documenting what I could figure out from the pictures of the Display board. Having pictures of the back of the board would really help in figuring out how it worked. https://dansdigitalarchaeology.blogspot.com/2023/03/cps-super-salt-error-display-board.html I also did a series of posts on how the test device works. Most of this information in in the Technical Manual but I simplified it a bit for my posts. https://dansdigitalarchaeology.blogspot.com/2023/02/atari-cps-supersalt-test-assembly.html https://dansdigitalarchaeology.blogspot.com/2023/02/atari-cps-supersalt-test-assembly-adc.html https://dansdigitalarchaeology.blogspot.com/2023/03/atari-cps-super-salt-sio-test.html https://dansdigitalarchaeology.blogspot.com/2023/03/atari-cps-super-salt-joystick-ports.html

This did get me thinking about the first game that "raced the beam". This definitely happened by 1978 with Breakout which does mid-line changes to the playfield to do the bricks. I think this may be a case of necessity if the mother of invention. The earliest games didn't need to push the limits of the hardware. But as time went on programmers started finding useful way to race the beam and get more out of the hardware.

I don't know if I would call "racing the beam" and accident. The system was intentionally designed to be flexible, and I am sure the engineers knew what was possible with it. The O2 and 2600 were just two different design approaches. The 2600 was very flexible, but harder to program. The O2 lacked the flexibility but it was much easier to get things on the screen. The O2 could easily do a lot of moving objects as long as some of them were from the fixed set of shapes. KC Munchkin uses the 4 sprites for your characters and the enemies, but the dots are one of the fixed shapes. The other difference was the processor. The O2's 8048 was slower then the 6502 and probably would have had a hard time doing the real time video register updates that the 2600 requires.

Yeah, that's one of the big challenges with the O2, the only graphics elements where you have complete control are the 4, 8x8 1 color sprites. One of the reasons why there weren't many games ported to the O2 from other systems.

There are a bunch here: https://virtualconsoles.com/

Archive.org uses a web based version of the MAME/MESS emulator to run software for consoles, computers, and arcade games. For example here is C64 River Raid: https://archive.org/details/d64_River_Raid_1984_Activision

I am in the process of repairing a Coleco Telstar arcade which would not power up. There is a simple voltage regular circuit in the corner of the main board which wasn't working. I replace the bad Q2 transistor, but then the CR3 zener diode burned out. Unfortunately it burned to the point where I can't read the part number. I can see IN75 but not the last two digits which are the ones that indicate the operating voltage. I also have not been able to find any schematics. I was wonder if someone has one of these if they could read the part number off that diode, or take a voltage measurement between the two points circled in red in the second picture.

Someone brought this to my attention. This is an auction of items from Atari engineer David Sherman which includes Missile Command and I-Robot prototype machines. https://www.rrauction.com/auctions/auction-details/650/?page=1&itemQty=24&view=gallery&sort=hp&cat=683

I started to dig into this and have run across a number of features in the assembler that Crystal Castles doesn't use.

In Crystal Castles there was a single root source file that included all the others so you only need to point the assembler at one file. I downloaded the Asteroids Deluxe code and I think DSTRD0.MAC is the root file. I tried assembling from that file but there was a pseudo op that isn't implemented in my assembler. If I have some time I may dig into this and make the changes to the assembler to be able to assembler this code.

Yes, I have built the tools necessary to re-create the ROMS that will run in an emulator. I haven't tried Asteroids Deluxe yet but I took a quick look at the source and it looks like it will work with this assembler.

Strange mod, those two pins are the bit 0 and 1 data lines from the CPU and the resistors connects these to ground so acts as a pull down resistor. Not sure why this was needed.

I liked Atari's DOS menu system, but the fact that there was no command in Atari BASIC to display a disk directory was really annoying.