paulrobson

Awesome

SDLMess has always been messy Looking at the source they have allocated $000-$7FF as ROM, and $800-$9FF as RAM, which is technically correct but an S2 allows ROM anywhere in the memory map.

Pacman for the Studio 2 is now downloadable from http://www.robsons.org.uk/pacman.zip Tested on EMMA02 but not MESS (don't have the right BIOS ROM images I think). Looking at the MESS source it should work This is a 1.5k Cartridge

You can have mine if you want. I don't collect RCA systems, I just develop stuff, and it doesn't work on PAL, but I think it does work

Next up : Pacman for the Studio 2.

Kaboom is ready to go - okay it's a beta probably, but it is complete and works. I have tested it on my own S2 development emulator and Emma02 and it works fine. Not tried MESS. Temporary storage, no proper hosting http://www.robsons.org.uk/kaboom.zip Source, Bin and ST2 format files included.

The S2 cartridges are unique AFAIK in that they are not mapped anywhere at all. It is purely convention that cartridges are 1k between 0400-07FF. You have to have ROM at $0400 because the BIOS does the "Chip 8" command $1400 - jump to $0400 but otherwise you can put anything anywhere except for $000-$3FF which is permanent. Studio 2 ROMS - CDP1831 chips - are masked to 'appear' at the correct address. Because only homebrew games use 1802 assembler (I think) , the rest are in the Chip-8 variant which can only access memory in the bottom 4k of the address space. So the address space from $1000-$FFFF can have anything you like - ROM, RAM, Video Hardware, Audio Hardware. The problem with your idea it you'd chuck out the whole thing really. The S2 sound is awful, but so is the graphics and the controllers and the processor.

Had a bit of tinkering time and wrote the basic display stuff for Kaboom/Studio 2. It looks messy here but actually it works quite well when its in motion, obviously the (err....) bombs are permanently on the move and with a bit of fiddling they're going pretty fast. Had to lose the man at the top for space issues.

Found http://www.old-computers.com/magazine/view.asp?r=1&a=14 so you should be able to test it with a meter. I've never actually had a real S2 working so I'm not a hardware expert.

I think it's the power to the system. The first thing an RCAS2 does when it powers up is squawk, this is through a speaker in the system console (i.e. not through the TV) so there's probably no power.

That's a bit pessimistic I had a look at Rear Guard and I think that's possible, though the parallax floor bit might have to go. Like a lot of older systems, you have to code for its strengths which are (.... thinks) well it can vertically scroll fast. Vertical movements can be fast because you don't have any bitshifting. Problems tend to occur when you have lots of sprites being drawn. I can make Rear Guard work, I think because the sprites are all the same and the player only moves vertically. I can cache the enemy sprite shifts. Something like Robotron where there are lots of different sprites all going at once would be almost impossible, notwithstanding the graphics problems. I reckon an S2 could do a cave type game, but having sprites moving at any sort of speed in that would be difficult. But that's the fun of homebrew on the S2 (and things like the VCS, Channel F), scamming the hardware into doing things previously thought impossible. This does have an impact on multicarts. I don't think this will fit in 1k of ROM. My multicart design allocates a whole 4k block for each cart image allowing ROM to be mapped in at $A00-$FFF giving 2.5k ROM space to play with. (400-7FF and A00-FFF). You could design it so that it just mapped out the standard 1k ROM between 400 and 7FF. Looking at Farnell a DIP 4Mbit Flash ROM is about £5. (Arranged as 512k x 8 bits, this would give 128 2.5k games in the cartridge). You'd also have to have some way of mapping out the upper 7 address bits. If you anded TPA and A7 this would give a positive going pulse whenever you accessed memory in the range $8000-$FFFF - one could use a parallel latch to latch A0-A6 (conveniently, 128 options !) to drive the upper bits - so attempting to read $A300 which no S2 cart would do, would select bank $23 (e.g. 010 0011) One problem is that the S2 has no reset line on its connector, so if you press reset on the console you will reboot the current ROM, not go back to the menu. Maybe the cart would have to have a reset button. I'll have a go at kaboom I think Nice fun game to warm up with.

I'm taking up the Studio 2 again for a bit, what sort of things would people like ?

Odd, the only one is mine and it definitely works. Dumping RCAS2 carts is not difficult, you have an address bus to write to (8 bits) one to read from (8 bits) and some lines to tweak (TPA to set the upper address, MRD to read the cartridge). I suspect the problem was the PC interface The wierd thing about it is that S2 ROM carts have the address decoders built in, unlike almost everything else which has a chip select line which is decoded in the console/computer, if you send it the wrong address values it doesn't respond. If you want to try again put me in touch with Guru and we can almost certainly figure it out between us - dumping the BIOS ROMs is much harder than dumping the carts.

If someone can get this cart reader working they're welcome to keep it or for it just to be passed round as needed I can understand someone who has (say) the Bingo cartridge not being keen on sending it to someone they don't know well.

I've dug out my old cart dumper. You can have that (save you worrying about where your rare cart has gone). Problem is I am now on Linux and the old s/w is for DOS, so I can't test it, it is a parallel port basher - don't know how that would work in newer Windows ? It does come with a Tennis ROM to test it with though that has been decased. It's a right rats nest of wires but it looks okay. It's the same design as on my old website.

Under development The sound does actually work, though it's a stable beep, not the warpy sound Awaiting delivery of a couple of 3x4 keypads, once that's done it's not much work to fix it up. The hard bit oddly is loading the ROM images in - at present you'd have to recompile it with modified ROM image.

BTW. I do have a Studio 2 if someone wants a test bed for a multi cart. As I am in the UK it is not a great deal of use (postage might be a problem ?) plus the Arduino one is easier to set up It is slightly modified (switch built in to disable 1802) but I think it works.

Hi. I am the bloke who wrote the Space Invaders cart about 10 years ago. My old website is at http://www.robsons.o...udio2/index.htm which contains various S2 things including the three homebrew games I wrote (Invaders, Pong and Combat) and their source. Please feel free to include them on any multicart or similar (though I've never tried them on a real Studio 2) and any content therein, view them as public domain software. Invaders is about as much as you can do. The system can't, for example, move the invaders individually, it's just too slow. What it does is remove all the bullets, scroll the whole of that bit of the screen and draw the bullets back again. Any game which involves lots of moving sprite objects that aren't fixed on byte boundaries is going to struggle because of the enormous amounts of bitshifting required (why 8080 Space Invaders has dedicated hardware to do this I guess ). Fundamentally the problem is there is no fast 16 bit shift in a 1802 ; you have to do GLO R4; SHR ; PLO R4 ; GHI R4; RSHR ; PHI R4 repeatedly which is horribly slow. Actually the big mistake, IMO, was the adoption of the 64x32 pixel format. Not the 64 across bit, but the 32 down. The 64 bit across is more or less mandated because you have a CDP1861 but if they'd used a 64x48 or even 64x64 format it's much easier to make the graphics look better in that space (I once designed a VM 64x48 mono games system running on an AVR8515 and those extra 16 pixels make a huge difference). Apart from the RAM shortage problem (64x64 => No user RAM) you can do it in software. There is also a circuit diagram for a cartridge dumper which runs off 2 74 series chips (SIPO and PISO shift registers) and connects to the parallel port (which I have built and tested and works) and a multicart (which I haven't built and tested). The thing to remember about the multicart is you have to return the ROMCS line to disable the internal ROM as cart images go over the 1k built in games not into open space. Far better for a modern cart reader would be to use an Arduino to drive the lines and send the ROM image back through the serial debugging port. The hard bit is the anti static. You have to stick two dowels up the holes in the cart sides, to shift the metal comb off the connectors. This is why an S2 has those big sticky out metal bars I've also extracted the Studio 2 ROM (using the open collector/second system approach the OP describes) and disassembled the Chip 8 interpreter bit of it (first 768 bytes) For those lunatics amongst you, I've just uploaded my latest project which allows a stock Arduino Uno/Due to become a Studio 2 using a keypad, buzzer and a couple of resistors - generates composite video on the fly and emulates the 1802, gives some idea how slow an S2 actually is It's in the files section http://dir.groups.ya...macelf/messages under ProjectVIP (it does a Cosmac and Elf as well) Comments: BassGuitari : Chip 8 games do not run on the S2. Whilst they look very similar, and the interpreter for the S2 is pretty similar they are incompatible - and it isn't just a matter of converting them either The graphics system is completely different, and some of the registers have special uses. I think when the S2 was being designed it was found that the DRAW system that Chip-8 uses was simply too slow and that the Sprite system (in the S2) was an attempt to speed it up by caching the bitshifted graphics so you didn't have all the shift/rotates that are required. The other problem is that an S2 is designed for ROM based games whereas Chip 8 ones are in RAM, so storage could be in the middle of the program or code could be self modifying. You could convert them, probably, from the original source but automatically would be a challenge. Lee's Rocket is in the EMMA02 Software archive (and probably other places) and he tells me he is working on other stuff, including (supposedly !) chess You could theoretically make Chip8 run on an S2, though you would run into problems with any code that stored variables in mid program or was self modifying, and almost every game stores variables in RAM after the program, which requires yet more unreliable hacks ToyMailMan: Virtually nothing can be done with s2 sound. That decaying squawk (caused by the Electrolytic Cap in the 555 circuit) is all it does. You can have a long one or a short one. You could theoretically modulate it as is done in Channel F's Pacman homebrew but it would be interesting, especially as you couldn't display anything at the same time because the CPU has to be interrupted to generate the video a la ZX81.