PCB Layout Image of New Bally Development System ------------------------------------------------ September 28, 2007 - Version 1.0 Messages gathered by Adam Trionfo All of this information appeared on the Bally Alley Yahoo Message board between May 13, 2007 and May 19, 2007. I've compiled it in a manner that makes it much easier to read. The people in this "conversation" are: Adam Trionfo, Paul Thacker, Lance Squire and Mike from 8-Bit Domain. Adam: [In reference to the Bally_development.pdf that was just uploaded to the message board.] I am very impressed by this; I had no idea that any work like this was going on. It's unusual to upload anything like this without an explanation. So, what are the details? Mike: I have been toying with the idea for several months of building a multi- platform game development system. I was mainly interested in consoles which have a true expansion interface like the Bally, Colecovision and Sega Master System, etc. By true expansion interface I mean most if not all address, data and control signals. These three consoles also have a common processor, the Z- 80 which I have worked with since the eighties. I wanted something more that just a simple multicart with a download port. So I designed this platform with its own processor and shared memory interface to the target console. This allows me to take control of the target address/data bus utilizing BUSREQ and BUSAK of the Z-80. Also I have a large expandable multibanked flash capability using the two 40 pin module sockets. The platform having its own processor also means that I can diagnose and repair defective consoles (assuming that at least the Z-80 works). The processor I use is the Atmel Mega128 with the Bascom AVR compiler. It does not have to be code compatible with the target since the target console is basically shared memory and IO. I can now write test routines for any memory or I/O device. The Bally may be more difficult because of the custom video chips. This Bascom AVR compiler source code would be open source and available to all to encourage a large database of software. What do you think? Lance: Sweet! What program was that layout done in? Mike: The schematic capture and PCB layout was done in PCAD. I also have their autorouter, but on boards like this one I would rather hand route. Paul: Wow, that is ambitious. By multi-platform, do you mean that the same development system would work with the Astrocade, Colecovision, and SMS, or just that there would be three systems with a similar set-up? Do you have a prototype built, yet? Does the Blue RAM Module have an audio interface? I can upload some digitally processed Blue RAM tape recordings if you want. Mike: Actually the platform has two connectors on the right hand side, one is the 50-pin Bally the other is a 60-pin Coleco connector, the SMS could be handled with a simple adapter. Also I forgot to mention it before but an additional feature of taking control of the bus is that the target can then become a reader/dumper for any cart plugged into the console. Paul: That would be convenient given our recent efforts to figure out where Ward Shrake's dumper ended up. Mike: I have just completed the layout so no PCB prototype is available yet. The Blue Ram interface has not been completed yet, but yes it will have an audio interface. I would like to find out more info on the 2000-baud interface and encoding method. Perhaps one if the Bally Alley members could provide this. Paul: I'd say Bob Colbert knows the most about it. He wrote Ballybin, which digitally processes 2000 baud recordings. You can get it here: http://www.ballyalley.com/program_downloads/tape_archive_tools/tape_archive_too ls.html The source code to version 1.4 is available. He's been working on v2.0, but it's still rather buggy. I made a bug report on it not too long ago. This is about the time he said he'd start looking at it. You might also consider looking into the 300 baud format. Some of the older programs will only work in this format, and the 300 baud interface is fairly rare. Ballybin doesn't currently support 300 baud recordings. Many more 300 baud programs will eventually make it onto Bally Alley. Adam: The Blue Ram Interface is not 100% compatible with the AstroBASIC-- we don't think, anyway. Paul: Well, the encoding format is close enough that Ballybin seems to work with Blue RAM programs, though some more testing on that point would definitely be nice. Adam: As for 300-baud-- there's no point. Bally BASIC would have to be modified to load 300-baud tapes from something off the expansion port. Paul: I guess it depends on just how much control the game development interface had. An alternative would be to give it a cable that plugged into the light pen port. Lance: Um, That would be the Joystick port. The Light pen port is just used as a power source. The joystick ports don't supply any, unlike Atari/Commodore. Mike: What method could you suggest that would take all of the existing tape files and convert them into text files? I assume that is what the save and load from all the basic versions do. These text files could then be saved and loaded into shared memory through the USB or serial interface. Forget 300 or 2000 baud transfers and think USB data rate transfers. Lance: [Text files are not created]. AstroBasic just does a RAM dump to tape, instead of deinterleaving and decoding the basic to ASCII. To drop Bally/Astro Basic programs in through a RAM interface would require the code and graphics to be interleaved before transfer. The BallyBin/AstroWav programs are your best bet on existing code to interleve/de-interleve and decode/encode. However it doesn't yet handle the variable pointers etc... Mike: I have seen the keyboard interface for the Blue Ram (what a mess) that is not the best way to enter programs, however it is much better then using the keypad. It seems to me that what is needed is creating/editing basic programs from the PC and then do the save and load through the USB and bypass BASIC. In that case no tape interface is necessary once the existing database of programs have been converted to text files. Any thoughts or suggestions? Paul: Well, the 2000 baud format essentially uses a straight binary memory dump. Ballybin produces binary files from .wav files. The newest beta version also has a specialized BML (Bally XML) format, and can try to do things like decode BASIC code into text. Some of these features are not yet working very well. 300 baud works quite differently. It essentially types commands and code into Bally BASIC one character at a time. It can also be used to load machine code directly--does anyone know the details of this? USB transfer would be a great feature for some programs, but keep in mind that these programs were often designed with delays in mind. A program might load a title screen animation, then have a delay, then load the main game, for example. Mike: Ok, is Astrobasic an interpreter or a compiler? Is this RAM dump to tape compiled machine code or interpreted source code? Can you explain the interleaving further? Lance: Astro Basic is the upgraded version of Bally Basic, sporting the 2000- baud cassette port on the cart. Both basics are interpreters. Now, as the 4K RAM in the Bally comprises the RAM required to display the screen there is no extra RAM to hold Basic tokens, variables or arrays. So Basic first sets 2 of the 4 colors to the same values as the other 2, then uses the alternate bits of each RAM byte to hold the basic tokens and array data. That is a byte of RAM looks something like this in Basic: GBGBGBGB (Where G is graphic image and B is Basic code.) As such it takes two bytes RAM to hold one byte of basic code. Mike: Wow, that really sucks. How about Blue Ram basic? Does it work the same? Lance: As Blue Ram and Viper Basic use RAM outside the display, I'm sure it's just the raw tokens etc. Much simpler to deal with. I, unfortunately, haven't seen (or remember seeing) internal details of the various extended basics. End of File