+llabnip Posted September 11 Share Posted September 11 ColecoDS is an emulator for all things Colecovision and ADAM for your DS/DSi/XL/LL: https://github.com/wavemotion-dave/ColecoDS Lots of recent improvements to the ADAM driver so that most games now load up properly and smoothly every time. Especially tricky were CP/M and T-DOS programs which should be mostly sorted out now. There is still the occasional program with the odd graphical glitch on loading - but these are now much fewer. I've also added a joypad/keyboard toggle so you can change between the main controller and the ADAM keyboard. The ADAM supports 256k digital data packs in .ddp format and disks of 160k or 320k in .dsk format. 6 Quote Link to comment Share on other sites More sharing options...
+llabnip Posted September 13 Author Share Posted September 13 I figured I'd leave some breadcrumbs for the next emulator developer as the ADAM emulation was tricky to work out properly. One major issue with porting from Col-EM was that the disk and data pack reads were "instantaneous" - meaning the disk buffer would move into place immediately. But clever programmers back in the day would use tricks like kicking off the next data read while they were reading the current buffer - knowing the disk access would be slower than CPU access of fetching the remaining data. So, essentially, by instantaneously filling the data buffer, the CPU would read the wrong data. This would cause all kinds of graphical glitches in games - making loading levels in Super DK impossible, etc. The trick is to delay the buffer fill - in ColecoDS, I used a simple mechanism of responding that the disk had a 'busy' status for 10 (completely arbitrary) checks by the CPU... this seems to be enough to allow virtually any disk based game to load properly. The other thing I discovered is that some games are very sensitive to the contents of what's in RAM. 0x00 and 0xFF didn't produce the best results and RANDOM was a crap-shoot. I notice that ADAMem uses 0x00 for even bytes and 0xFF for odd bytes - I still can't figure out why... but I've settled on using two RAM patterns depending on the type of game. I clear RAM to 0x30 for all ADAM games except CP/M games (easily found by searching for "CP/M" in the .dsk file) where I use 0x38. These were found experimentally by me - other patterns seem to work, but these are what I settled on. I have no documentation to back up these patterns other than they work for the vast majority of the ADAM library. Lastly, and mainly thanks to @NIAD for pointing me in the right direction, small graphical glitches on some title screens (such as Adam Bomb 2) required that the TMS9918/28/29 VDP registers be initialized in a certain way - the same way as ADAMem did: 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 25 Share Posted September 25 The VDP registers aren't guaranteed on startup... something has to be setting those values. That said, now that I've actually had to look... the datasheet doesn't explicitly say and I have never run a system that doesn't init the registers before I get control, so I guess I can't prove it I believe ColecoVision carts that bypass the delay also bypass all VDP init, so could test the theory there... 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.