nitrofurano Posted June 22, 2013 Share Posted June 22, 2013 (edited) Hi everyone! Recently i got successful on creating .rom files for MSX using Boriel's ZX-Basic Compiler. My idea is to do the same for ColecoVision, since it is a hardware very similar to MSX1, since the main differences are the i/o ports, memory arrangements, bios-like routines (or lack of them). What i have posted on forums, available to download (.rom and their sources) are at http://www.boriel.co...m/post4575.html and http://karoshi.auic....hp?topic=2479.0 I'm curious for your comments! cheers! Edited June 22, 2013 by nitrofurano 2 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted June 22, 2013 Share Posted June 22, 2013 Yes, yes please! Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted June 27, 2013 Author Share Posted June 27, 2013 (edited) for now, what i need is documentation about how the .rom files are made (they all seem to start with 55AA0000 hexdump signature?), which area is for ram memory and how large is it (1kb?), which is for rom bios (8kb?), which are the bios routines addresses, which system variable are and where are they placed on ram (if used from the bios), which are the i/o ports for video memory, sound, controls, etc. Edited June 27, 2013 by nitrofurano Quote Link to comment Share on other sites More sharing options...
+nanochess Posted June 28, 2013 Share Posted June 28, 2013 All ROM files are mapped to 8000 hex. Starting with signature 55 AA (no starting Colecovision screen) or AA 55 (Colecovision screen with game title), more info at http://www.emulatronia.com/doctec/consolas/colecovision/CV-Tech.txt The address 800A contains the address for program start. The VDP standard access ports are $BE (Address) and $BF (Data). The VDP Interrupt is connected to NMI (this was INT in MSX), the non-maskable interrupt is a little difficult to handle, just make sure you end your interrupt routine with RETN. If you don't use interrupts then is easy to use VDP. Otherwise you will have to use semaphore code so VDP access isn't crashed by NMI interruption. The PSG standard access port is $FF, it is very similar to MSX one. Access to joystick and keypads is also straightforward. Quote Link to comment Share on other sites More sharing options...
CrazyBoss Posted June 28, 2013 Share Posted June 28, 2013 and memory is 1024 bytes from $7000, its mapped/mirrored to other addresses. You cant use all 1024 bytes safely cause of the stack. Bios calls also uses some specific addresses. I have seen games which dont use any bios calls at all. Eg. Spectron by Spectravideo. thats why it was pretty easy to convert this to Memotech MTX You can read joysticks and keypads by one out and one in command, it returns a bit-pattern to check which status the keypad or joystick have. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 28, 2013 Share Posted June 28, 2013 Did the Sega Master System port of ZX Basic die? I'd love to see it on the Coleco too, though! Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted June 29, 2013 Author Share Posted June 29, 2013 Did the Sega Master System port of ZX Basic die? I'd love to see it on the Coleco too, though! The efforts of Haroldo (SMS port) were known from Boriel, and they both are in contact on Facebook and Google+ as well - Boriel is extremely interested on extending ZX Basic to other platforms, these (somehow) successful SMS, MSX and MC-1000 (a rare Brazilian GEM-1000 clone) ports were considered as a main documentation for this extension process. (he personally is interested on extend himself ZX Basic to Amstrad-CPC, for example) And since i got really amazed with the progress on the MSX port (even MSX2+ display modes works, but i'm struggling on v9990 due on lack of simple and good enough documentation available), i really wanted to extend this MSX1 experience to both ColecoVision (just started to type some code, not tested yet) and Sega SG-1000 All ROM files are mapped to 8000 hex. Starting with signature 55 AA (no starting Colecovision screen) or AA 55 (Colecovision screen with game title), more info at http://www.emulatronia.com/doctec/consolas/colecovision/CV-Tech.txt thanks! on the MSX, from ZX-Basic, i'm using a kind of 16byte rom header, 41421040 00000000 00000000 00000000 , and the compiled code starts on 0x4010 - i think i can do the same on ColecoVision, having also a 16 byte rom header like 55AA0000 00000000 00001080 00000000 , and having the compiled code starting at 0x8010 ? about interrupts, i think that using Halt for wait-vbl may create some problems on i/o vdp? i were seeing also that the ColecoVision bios routines seems to be not enough? sometimes with some differences on the registers used, write_vram (cv) seems similar to ldirvm (msx1), read_vram (cv) seems similar to ldirmv (msx1), fill_vram (cv) seems similar to filvrm (msx1), but what is similar to wrtvrm and rdvrm? (which i use all the time on msx1? is that the only way using i/o ports, $BE and $BF somehow? i forgot how to write and read vram memory (just like using wrtvrm or rdvrm) with i/o! ) and memory is 1024 bytes from $7000, its mapped/mirrored to other addresses. You cant use all 1024 bytes safely cause of the stack. i'm concerned with this, i struggled a lot using Boriel's ZX-Basic Compiler for creating roms for PacMan arcade hardware, maybe because limited ram size as well... :S Bios calls also uses some specific addresses. I have seen games which dont use any bios calls at all. Eg. Spectron by Spectravideo. thats why it was pretty easy to convert this to Memotech MTX You can read joysticks and keypads by one out and one in command, it returns a bit-pattern to check which status the keypad or joystick have. Memotech MTX! i also want Boriel's ZX-Basic Compiler targeting it! \o/ Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted June 29, 2013 Author Share Posted June 29, 2013 i'm just attaching a kind of template based on the first msx1 examples i did (of what i have available at http://nitrofurano.altervista.org/retrocoding/msx/index.html ), and started to recode it for colecovision - it is still incomplete and not tested, and surely will not work - but i think it's over 90% close to have it working! - any help there is very welcome! colecovision_borielszxbasiccompiler_experimentalsnippets_201306290903.zip Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 29, 2013 Share Posted June 29, 2013 It's just starting to click that YOU are doing this port to the Coleco! Thank goodness!!! I'm sure that you'll take this to version 1.0 I'm not sure how I can help but use your ZX Basic for Coleco and report back bugs. Three cheers for nitrofurano! P.S. It looks like SG-1000 games might run on a Sega Master System. The difference seem to be in the colors and BIOs. 1 Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted June 29, 2013 Author Share Posted June 29, 2013 (edited) It's just starting to click that YOU are doing this port to the Coleco! Thank goodness!!! I'm sure that you'll take this to version 1.0 I'm not sure how I can help but use your ZX Basic for Coleco and report back bugs. Three cheers for nitrofurano! thanks, @theloon ! btw, i'm starting to have some results, even not satisfactory enough - btw, the .asm (who can help us debugging? ) and .rom files are being created (figuring out with some hex-editors might help as well...) - and i'm still far for having decent libraries as i have available to the msx1 version, such as essential things like vpoke, vpeek, setting display modes, moving sprites, reading controls, outputting sound, etc. (but, any progress is very considerable and welcome!) P.S. It looks like SG-1000 games might run on a Sega Master System. The difference seem to be in the colors and BIOs. i think that SG-1000 and Mark-III has no Bios at all, everything i/o! colecovision_borielszxbasiccompiler_example01b_notworking_201306291802.zip Edited June 29, 2013 by nitrofurano Quote Link to comment Share on other sites More sharing options...
hardhat Posted July 25, 2013 Share Posted July 25, 2013 Looks cool. I'll have to give this a try. I'm not sure if you should be using the BIOS or not. I know that there are "Pascal entry points" for most bios routines as well as the regular entry points, but the disadvantage of using the BIOS calls is that there are a bunch of reserved RAM addressses in the $7000 block of memory. I usually use the BIOS extensively in my code, and so any compiler work I've done is oriented that way. Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted July 25, 2013 Share Posted July 25, 2013 Promising! But I've got to wonder... will this compiler handle sprites? The ZX Spectrum doesn't support them, so this compiler would have to be expanded to deal with them. Otherwise, you're going to have a lot of games with tiled graphics and choppy movement. Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted September 7, 2013 Author Share Posted September 7, 2013 Promising! But I've got to wonder... will this compiler handle sprites? The ZX Spectrum doesn't support them, so this compiler would have to be expanded to deal with them. Otherwise, you're going to have a lot of games with tiled graphics and choppy movement. yes, handling sprites as fine as i got from the msx1 version (you can find examples at http://nitrofurano.altervista.org/retrocoding/msx/ ) - btw, from Boriel's ZX-Basic Compiler i'm getting only that compiling support, and avoiding all issues related to ZX-Spectrum hardware Looks cool. I'll have to give this a try. I'm not sure if you should be using the BIOS or not. I know that there are "Pascal entry points" for most bios routines as well as the regular entry points, but the disadvantage of using the BIOS calls is that there are a bunch of reserved RAM addressses in the $7000 block of memory. I usually use the BIOS extensively in my code, and so any compiler work I've done is oriented that way. for now, i'm curious about code in assembly that i could use as library there, calling the bios or not... (i'm struggling on this part, since i'm not yet that comfortable with Colecovision hardware as i am about msx1 hardware, even considering both hardware are very similar) Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted September 8, 2013 Author Share Posted September 8, 2013 updated http://nitrofurano.altervista.org/retrocoding/colecovision/index.html - for now, only one example from Daniel Bienvenu is working (that one from youtube, the second "hello world" example he has there - i'm struggling on having his sprite examples working, and i'm also curious on testing other .asm snippets this way) Quote Link to comment Share on other sites More sharing options...
newcoleco Posted September 12, 2013 Share Posted September 12, 2013 updated http://nitrofurano.altervista.org/retrocoding/colecovision/index.html - for now, only one example from Daniel Bienvenu is working (that one from youtube, the second "hello world" example he has there - i'm struggling on having his sprite examples working, and i'm also curious on testing other .asm snippets this way) I've took time to download and look at the colecovision_borielszxbasiccompiler_20130908202020.zip file The first thing that's clear to me is that the CV header is incomplete and so, I might say, the code ends up not at the right place which makes for example the sprites demo not working. For instance, the absence of the label at the correct place in the header for the NMI routine screw up the entire execution. I'm not sure how you can manage to fix this, but here is what I have for my C programs. The header is structured simply as this : ;; CARTRIDGE HEADER (IN ROM) .area _HEADER(ABS) .org 0x8000 .db 0x55, 0xaa ; no default colecovision title screen => 55 AA .dw 0 ; no copy of sprite table, etc. .dw 0 ; all unused .dw _buffer32 ; work buffer (RAM ADDRESS OF COURSE) .dw 0 ; ?? .dw start_program ; start address for game coding .db 0xc9,0,0 ; no RST 08 support .db 0xc9,0,0 ; no RST 10 support .db 0xc9,0,0 ; no RST 18 support .db 0xc9,0,0 ; no RST 20 support .db 0xc9,0,0 ; no RST 28 support .db 0xc9,0,0 ; no RST 30 support jp spinner_int ; RST38 - spinner interrupt jp _nmi_asm This header covers 90% of the needs for new CV projects. You may decide to replace the reserved buffer space (_buffer32) by simply a null value 0, it depends if you are gonna use some of the BIOS routines or not. If you wanted to see the default ColecoVision screen that last 10 seconds, the TEXT used for the title, company and year should be right next to this ROM header, and the first part being AA 55 instead of 55 AA. In this header again, I've setup a buffer to be 32 bytes long, which is enough for some graphic routines in CVBIOS which are unused by homebrewers so far. These 32 bytes are enough for REFLECT VERTICAL $1F6A, HORIZONTAL $1F6D and ROTATE90 $1F70 (ref.: CV coding guide). But why 32 bytes? Because of a strange but true fact about CV sound routines. CV Sound routines in the BIOS needs information stored in $7020-$702A as SOUND ADDRESSES and $702B..?? as SOUND SLOTS (10 bytes each slot, plus an extra byte at the end to say "no more sound sound slot"). So we end up with a very short space of 32 bytes $7000-$701F which I think was used in a primitive version of the CV BIOS as a table for the sprites reordering. You can surely decide to go with your own sound routines and so avoid the strange RAM usage starting at $7020, it's really up to you. So my RAM mapping starting at $7000 looks like this usually : ;; TABLE OF VARIABLES (IN RAM) .area _DATA _buffer32:: .ds 32 ; buffer space 32 [7000-701F] snd_addr:: .ds 11 ; sound addresses [7020-702A] snd_areas:: .ds 61 ; 5 sound slots + NULL (00h) [702B-...] _no_nmi:: .ds 1 _vdp_status:: .ds 1 _nmi_flag:: .ds 1 _joypad_1:: .ds 1 _keypad_1:: .ds 1 _joypad_2:: .ds 1 _keypad_2:: .ds 1 spinner_enabled:: .ds 1 As the program starts, the first thing you want to do is to set "im 1" to first make sure that, if you are gonna use the steering wheel, roller controller or even the little spinner on the SuperAction joysticks they will work with this header. The second thing is probably "di" to deactivate by default getting interupts from the spinner (why? because interuptions mean stopping your code at any random point which may affect the end results). Then, a nice cleam up of the RAM space with a simply ldir opcode. What I do next is setting up sound tables, screen mode, graphics, etc... you know, the fun part. start_program: im 1 ; interrupt mode -> rst 38h di ; disable spinners by default xor a ; clear carry ld bc,#0x3b8 ; ram size left ld hl,#0x7000 ; starting from 7000 ld de,#0x7001 ld (hl),a ldir ; zero-fill bss I hope this little introduction of the CV header helps your decision on how you are gonna approach this CV header "complexity" and make it simple for you. Good continuation! P.S.: I saw your message in my Youtube, a bit late but I saw it. 2 Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted November 4, 2013 Author Share Posted November 4, 2013 thanks for your feedback, Daniel, and sorry from my late reply! - asap i'll apply these notes and see what happens, also on games like this: http://karoshi.auic.es/index.php/topic,2523.0.html - thanks again and cheers! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.