Jump to content

Photo

ColecoVision stuff from Boriel's ZX-Basic Compiler, about to start

colecovision msx boriel zxspectrum basic

15 replies to this topic

#1 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • 260 posts
  • meditating
  • Location:porto

Posted Sat Jun 22, 2013 10:24 AM

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 by nitrofurano, Sat Jun 22, 2013 10:25 AM.


#2 Cybearg OFFLINE  

Cybearg

    Dragonstomper

  • 950 posts

Posted Sat Jun 22, 2013 5:07 PM

Yes, yes please!

#3 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Thu Jun 27, 2013 3:40 PM

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 by nitrofurano, Thu Jun 27, 2013 4:01 PM.


#4 nanochess OFFLINE  

nanochess

    River Patroller

  • 4,965 posts
  • Coding something good
  • Location:Mexico City

Posted Fri Jun 28, 2013 8:52 AM

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.emulatron...ion/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.

#5 CrazyBoss ONLINE  

CrazyBoss

    Moonsweeper

  • 327 posts
  • Location:Skåne, Sweden

Posted Fri Jun 28, 2013 9:41 AM

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.

#6 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Fri Jun 28, 2013 9:44 AM

Did the Sega Master System port of ZX Basic die? I'd love to see it on the Coleco too, though!

#7 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Fri Jun 28, 2013 6:36 PM

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.emulatron...ion/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! :D )

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/

#8 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Sat Jun 29, 2013 2:07 AM

i'm just attaching a kind of template based on the first msx1 examples i did (of what i have available at http://nitrofurano.a.../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! :)

#9 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Sat Jun 29, 2013 9:03 AM

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.

#10 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Sat Jun 29, 2013 11:13 AM

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! :D

Edited by nitrofurano, Sat Jun 29, 2013 11:15 AM.


#11 hardhat OFFLINE  

hardhat

    Moonsweeper

  • 316 posts
  • ColecoVision programmer/advocate
  • Location:Toronto, Canada

Posted Thu Jul 25, 2013 1:40 PM

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.

#12 Jess Ragan OFFLINE  

Jess Ragan

    Phanto of the Opera

  • 9,682 posts
  • Keys and Thank You
  • Location:The Arid Zone

Posted Thu Jul 25, 2013 5:54 PM

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.

#13 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Sat Sep 7, 2013 10:08 AM

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.a...etrocoding/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)



#14 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Sun Sep 8, 2013 7:59 AM

updated http://nitrofurano.a...sion/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)



#15 newcoleco OFFLINE  

newcoleco

    Stargunner

  • 1,276 posts
  • Always Tired
  • Location:Quebec

Posted Thu Sep 12, 2013 9:09 AM

updated http://nitrofurano.a...sion/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.



#16 nitrofurano OFFLINE  

nitrofurano

    Moonsweeper

  • Topic Starter
  • 260 posts
  • meditating
  • Location:porto

Posted Mon Nov 4, 2013 10:28 AM

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....pic,2523.0.html - thanks again and cheers! :)







Also tagged with one or more of these keywords: colecovision, msx, boriel, zxspectrum, basic

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users