flip

Not as far as I know. It hasn't shown up in any auction that I've seen (as opposed to the five other carts).

Sure - send me a private message and i'll give you the details FliP

The .ST2 filetype is a .bin file with an additional 256 bytes header that specify things like where to load the binary in an emulator. The structure of the header is as follows (courtesy of Paul Robson, who I believe came up with this format) Offset Contents Reqd Notes 0-3 Header Y RCA2 in ASCII code 4 Blocks Y Total number of 256 byte blocks in file (including this one) 5 Format Y Format Code (this is format number 1) 6 Video Y If non-zero uses a special video driver, and programs cannot assume that it uses the standard Studio 2 one (top of screen at $0900+RB.0). A value of '1' here indicates the RAM is used normally, but scrolling is not (e.g. the top of the page is always at $900). 7 - 8,9 Author N 2 byte ASCII code indicating the identity of the program coder. 10,11 Dumper N 2 byte ASCII code indicating the identity of the ROM Source. 12-15 - 16-25 Catalogue N RCA Catalogue Code as ASCIIZ string. If a homebrew ROM, may contain any identifying code you wish. 26-31 - 32-63 Title N Cartridge Program Title as ASCIIZ string. 64-127 Block Pages Y Contain the page addresses for each 256 byte block. The first byte at 64, contains the target address of the data at offset 256, the second byte contains the target address of the data at offset 512, and so on. Unused block bytes should be filled with $00 (an invalid page address). So, if byte 64 contains $1C, the ROM is paged into memory from $1C00-$1CFF 128-255 - 256 Block 1 (Page address at 64) 512 Block 2 (Page address at 65) and so on Not sure which python script you are using (possibly from Paul Robson's github?) This is probably using python2 and running it on python3 could create issues. For a quick hack, the easiest is probably to copy the first 256 bytes from an existing .st2 file and insert this before your .bin using a hex editor. If your .bin is compiled for $0400, then the only thing that might need to be changed is the byte 4, the length and the block pages. So if your program is less than 256 bytes, byte 4 should be $02 and the block pages should be $04 $00 $00 $00 ... If your .bin is <=512 bytes, then byte 4 should be $03 and block pages should be $04 $05 $00 $00 ... Hope this makes sense. If you still have problems compiling, feel free to PM me FliP

Hi all, Sad news that was posted on the CosmacElf group: Ed Keefe suddenly passed away on Sat Feb 5. Ed was quite active in this group and a great source of info on the 1802 CPU and all related things. His website (www.cosmacvip.com) is a goldmine for Cosmac and Studio II info and he helped out with the initial multicart hardware. He was always ready to help and I will miss his input and wisdom... RIP @ekeefe FliP

send me a private message FliP

Hi again, I have Azya52's race game running on an unmodified multicart. As indicated before, the multicart does not map $a00-$bff to the cartridge, so I remapped the game to use $100-$7ff and $c00-$fff. Pointers and interrupt are initialised from $000 onwards - the rest of the kernel is left out. I am sure there's a more elegant way of doing it, but it works... Interestingly, this leaves more space for game expansion (though this may need additional shuffling; $400-$4ff is currently not used). To use the game, it needs to have the system's kernel switched off (jumper or switch on the multicart). I've forked Azya52's git to include a new .asm file specifically for the multicart hardware. Due to the exotic timings and resolution, it doesn't run on the PAL clones (MPT-02 & co) or not in any usable way... Attached is a new image that has the racing game in slot 6-0. You'll need a programming device that supports a 39sf040 flash rom (and probably an adapter for PLCC devices). The chip cannot be reprogrammed while on the cart... FliP 39sf040.auto.bin

Hi all, I've managed to get Azya52's racing game running on real hardware. It won't run on the multicart for the moment without a hardware modification unfortunately: an extra address block ($a00-$bff) needs to be mapped to the cartridge. This requires an extra bit of logic on the cartridge. It *might* be possible to shuffle things around, so the game uses $000-$7ff and $c00-$fff, which would make it run on the multicart. Part of the initialisation routine that gets the console up and running would need to be inserted in the code... Interestingly (at least I think it is): my monitor shows some color bleeding around the edges of the objects. Regular games don't do this, so it might be that the timings/higher resolution resemble a PAL signal more than the normal resolutions. Incredible effort by Azya52, stretching the machine to its limits! FliP

Probabl probably why it was never used, in combination with the price of RAM at the time... 192 could be related to the number of lines available in PAL - the total lines =312, which is almost 1/2 of what is available in PAL (625). So each "line" is painted twice on the PAL screen. Interestingly, if you run Studio II games on the PAL consoles using the Studio II kernel, part of the screen is duplicated: the interrupt routine is timed wrong, so it starts redrawing the screen before the beam has reset to line 0. FliP

Pixels and colours used different ram space - there's a third ram chip in the PAL clones. The maximum resolution for the CDP1864 (used in the PAL/color systems) was actually 192x64, but that would have required 1.5k RAM for the pixels, or 6 times what they had in those consoles... FliP

Extremely impressive - the 1861 allows a number of different video resolutions, but the available RAM limits what can be used. I assume there's some clever trickery involved, as 64x128 would normally need 1k of RAM (Studio only has 2 x 256 bytes) it'll be a bit of a challenge to get this running on real hardware, or at least on my multicart. The game uses the $a00-$bff range. In my multicart design, these are not mapped to the cartridge ROM so they are not usable. There may be a way, assuming the game doesn't rely on any kernel routines (by moving the program around and not using the on-board ROMs, in the $000-$3ff range). Still, awesome effort and looking forward to further development... FliP

There was someone working on a 3D model. He had scanned in a cartridge and was converting the scan. I asked a while ago, and I believe he said he abandoned it due to other commitments. He was going to forward the files, but haven't heard back since... The cart works perfectly without a shell - there's no pins to push down and it's clearly marked which side should face the front of the console... FliP

Also, please note that due to the Coronavirus measures, I am unable to post outside Europe for the moment... I advise to wait until things are back to normal. FliP

Hi, Also, please note that due to the Coronavirus measures, I am unable to post outside Europe for the moment... I advise to wait until things are back to normal. It worked for everyone else so far since i started selling these, including someone that transferred money just last week... Not sure what the problem is you are having, but please make sure you use https://www.paypal.me/pmarien It shouldn't ask for an e-mail address? FliP

Hi, Thanks for your message. Two problems unfortunately: I don't have any shells anymore. I had about 15 donated for the initial batch, but they ran out within days... If you have a donor shell, it's easy enough to put the cartridge in... Second issue is that, for the moment, I cannot post to the USA due to the COVID-19 problems. I am in Europe and I have no idea when those services will restart. I'll keep an eye out and let you know, but it could be a few weeks or months... regards, FliP

Is that not what @ekeefe posted about? The cartridge runs in Emma 02 (cart is called computer.st2) if you want to see it "action", but it's fairly cumbersome to use, having to type is code via the keypads, byte by byte and without a way to save it. You don't need extra RAM, but you only have about 200 bytes to play with... FliP