paulrobson

There's a lot of machines this could be. There is a sequence of them starting with System00 (TTL CPU) various FREDs (1801 CPU) Cosmac ELF/VIP (1802 CPU). The 1801 is a 1802 without the long branch/skip, most of the shift rotates and load without advance. There are also different version of Chip-8 - at least three, the one that is well known that is part of the VIP, The Studio 2 version and the Fred version which is called FEL-1. Joyce W seems to have been programming all of them. They are all different ; though FEL-1 is much closer to Chip 8 graphically. FRED 2 (the naming is a bit vague as to what is what) was produced in small numbers (about 20) to demonstrate to potential buyers. To confuse matters furthers, the FRED papers I acquired from Hagley also have a design for a Cosmac Coin-Operated machine (1801 based) which appears to have been constructed at some point but got no further. It is interesting how different things could have been if different management decisions had been made in respect of the 180x stuff. This stuff predates Space Invaders.

I forgot that Flip wrote a test program which is on the multicart which includes a RAM test, did you try that ? The cart port is fairly chunky, should be fairly reliable ?

I can't see why your console would behave like that. Every reset/power up should be a fresh start. There may be some bugs in the games but not something that obvious. So if you reset Space Invaders it should work again even if there is a bug. Most of the other games (all ?) use the built in Chip-8 type language which uses memory in a very specific way, whereas my games use it in different ways. Maybe a stuck bit in the data RAM memory or something ?

Flappy bird would be fairly easy but I'd do it differently. Invaders would be more appropriate. Invaders can't move the invaders invididually, the 1802 just can't cope, so what it does is remove all the bullets, scroll the whole screen left, right or down as far as the bases, and then draw the bullets back again. Flappy could work the same way ; remove the bird, scroll the whole screen left, draw the bird back, check for collision, draw in the right hand wall and loop.

Okay, the github version of Invaders now has no LBanything LSanything or NOP. I don't think there are any other three cycle 1802 instructions. I've played it a bit and it seems to work fine. You might want to test it but I can't see any reason it should be problematic, it works okay in emulation. I wrote that sixteen years ago ... makes me feel very old. Interesting coding, I appear to have written it as one long bash ... not very modular ... and just used long branches to work round the paging .... still those three were about the first 1802 code I wrote. I notice Combat and Hockey have had some not all of the LBRs fixed. Are the glitches if any in these barely noticeable ? If so, I will just leave them alone if they work okay, so you can get your carts out.

I've sent you an invite to push to the repo - if you want to update it or send me your changes via email (paul@robsons.org.uk), then I can work on Invaders.

Okay, I have set up a repository at https://github.com/paulscottrobson/studio2-games. The three problematic games are the old ones, Combat, Hockey and Invaders which were written before I knew about the 3-cycles issue. I probably won't have time tomorrow but should get it done over the weekend - hopefully !

I will try and get it done in the next couple of days. I'll let you know.

Hi. Thanks for the offer, but I haven't got any way of running it. What's the timescale for sending these out ? I can have a crack at upgrading Invaders (I've obviously learnt for the new ones !) Paul Robson

Question : if I write any more Rcas2 games, to make them compatible with this what memory can I use, beyond the obvious (400-7ff) ? Is it just c00-Fff ?

I didn't know that, I must try it out. My 2711 project was actually running on a genuine CP1610 emulator but I rewrote the whole thing, It was actually running an RISC VM on top of the CP1610 and the game cartridge run on that. I worked the game out from the box pics and the instructions and I suspect it's pretty accurate The AY-3-8800 is so bad a design that it's instant-sacking. Given the expense of producing the chips. It's horribly limited in ways you can't begin to believe until you understand the datasheet. If it wasn't for the fact that it was in a databook with a bunch of other GI chips I'd have assumed it was a wind up. The design of the 2711 is also horribly botched. Externally and internally. It throws away a lot of the advantages of the 1610. I'm quite surprised the carts were dumped. Unisonics are incredibly rare.

The original : http://www.robsons.org.uk/archive/www.classicgaming.com/studio2/cart.htm

I noticed this old post while trying to find something. I've got this working - it was an outgrowth of my VIP project - basically the same thing with a different keyboard and memory map Though it doesn't emulate the RCA2 interpreter, in emulates the 1802, and generates the display at the same time, which says something about how slow the Studio 2 is It's an Uno or other 328 based Arduino (the Leonardo's don't work), a couple of resistors, a piezo buzzer and a pair of 3x4 keypads - the video is a heavily modified version of TVout I'll dig it out and upload it.

Update to Studio 2 homebrew - probably the last for a while - Berzerk. http://www.robsons.org.uk/homebrew.zip Though I will update them to have porting notes in case anyone wants to port them to Elf, Cosmac VIP etc. which is not difficult.

Not that anyone knows about. But who knows what's out there in prototype land

I've now finished my RCAS2 Scramble - see below. The download also contains all the other homebrews, and I've modified the 1k+ carts to map to $C00-$FFF, and to build with asmx. http://www.robsons.org.uk/homebrew.zip

I've got a rebuild of this on my desk as I write. It is a standard 555 astable circuit with the upper resistor 400k (2 x 200k in mine) and the lower resistor 480k (470k in mine). I measured these (I think) so they probably are 390k and 470k resistors as 400/480 are not standard sizes. The capacitor is 2.2nf. I don't know if there's a speaker driver on the output, this circuit is sufficient to drive a Piezo Buzzer. The 'wrinkle' is that the cap from 5 to ground is a 10uf electrolytic not a 10nf poly cap as one would normally use. This makes it sound like a foghorn with a rapid pitch decay over about 1/4 second or so. Everything else is as per a standard 555 astable circuit. It does mean you can get a couple of different tones out of it.

The schematic is fairly self explanatory ; if you cross the Cosmac Elf schematic with my technical information and the online schematic of the switch box that exists somewhere, that's basically it

Looks similar to my design, a latch to latch TPA, some address logic decoding and a more standard ROM. You don't need anything else to work, as you can use the RAM from $800-$8FF except for the around $8CE where there are three timer bytes - but then you could replace the video driver. Hard work though.

You're right ; the other thing is called a Visicom or something like that

I think knowing that much about this thing is a sign of being a bit mad Technically, no it doesn't. I presume you are mapping the 1k of Memory in at 0400-07FF. All the homebrews I've written take an extra 512 bytes between 0A00 and 0BFF. It would be trivial to change them to run anywhere in ROM, on a 2k mapping the easiest thing would be 0C00-0FFF. (In a classical S2 design it doesn't matter because of the self-mapping ROM images). This also offers compatibility with the Victory and MPT-02 I think - one does not use it, and the other has ROM there which would be disabled by the usual mechanism (the disable line back to the RCAS2) In theory undiscovered carts could fit literally anywhere in the memory map even where the RAM is (accessing the RAM elsewhere). However it is almost 100% certain that they will all be 1k or less and be put in 400-7FF Bingo might, just might have its ROM stuck in at 400-5FF and A00-BFF but it almost certainly won't. Here's a suggestion. If you use 2k for every cartridge you are wasting space. Most cartridges are 1k. I'm working on another Homebrew (Scramble) which will be <2k. I can't see anyone having the patience to write more than 2k of ROM really. The graphics aren't worth it. You could write a Zelda a la Pacman but it would look horrible Presumably you are decoding for x400-x7FF e.g. you are decoding on A11 = 0 and A10 = 1 - this selects your ROM and maps it in when any sixteen bit address matches xxxx 01xx xxxx xxxx and maps out the built in RAM mirror at C00-DFF (so you'd have to use ROMDIS *and* ROMCS) If you extended it slightly, so you decode only on A10 = 1 - so your ROM maps into xxxx x1xx xxxx xxxx then it will map the ROM in x400-x7FF and xC00-xFFF - so there will be 32 mirrors throughout the 64k address space, none of which matter. If you then take the A11 line - which is 0 for x400-x7ff and 1 for xC00-xFFF and OR that with A10 of the 32k ROM you are using for the mirroring then this will force every even page to be mapped to C00-CFF. (A0-A9 select the 1k ROM as normal - presumably A10-A14 are latched on the read from 80xx but tbh it wouldn't matter if it was 8000-FFFF i.e. you just used AD15 of the 1802) This would I think give you the following mapping, dividing the 32k EPROM into 1k pages A10-A14 (EPROM) 400-7FF C00-FFF =============== ======= ======= 0 0 1 1 1 1 2 2 3 3 3 3 4 4 5 5 5 5 6 6 7 7 7 7 and so on. Without the OR tweak it would just match each page to the selected page. With it it forces the page that is mapped to C00-FFF to be an odd numbered page (because A10 of the 32k ROM is forced to '1' by A11 from the 1802). With this arrangement you won't waste any pages. 1k games can go in any of the 32k pages. 2k games only need to go in even numbered pages so their code is in the two chunks. Code is mapped to C00-FFF but that is an irrelevance. The only catch is that some of the paging options will not run a game - in the example above if you put invaders in page 6 and 7 it will map the first 1k to 400-7FF and the second 1k to C00-FFF when selected, but if you select page 7 it puts the second half of the code in both spaces, which will not work. You are still wasting cartridge space for 512 byte ROMs. But other than that this arrangement should work on the Victory and MPT02 if (1) Marcel's documentation is right and (2) there isn't any BIOS code in C00-FFF in the Victory, which has ROM at C00-FFF but only for its built in games, which doesn't matter if you are running a cartridge game. I'd make sure it works first though - this is a theoretical design I never built the version on my old website, though it should work in theory.

Are you only supporting 1k Games ?

Do you think it is too easy ? It can a lot quicker than it does at the start (it gets harder as you go on, more asteroids etc.) Maybe I should add a difficulty switch ? There is about 130 bytes left in that cartridge so it's not hard to tinker. Pacman has about 8 bytes left which is why the score appears at the top rather than in the middle - it wouldn't fit otherwise

Another new game. Asteroids Somewhat challenging this one, lots of things moving about the screen. No UFO and the controls work slightly differently (push to move not thrust in zero G) http://www.robsons.org.uk/asteroids.zip

Does it support PAL video as well ?