Jump to content
IGNORED

[AQUARIUS] Micro-Expander: RAM, ROM, AY-8910 and more!


Bruce Abbott

Recommended Posts

This project is an attempt to squeeze all the functionality of the so-called 'mini' expander into a single cartridge. The prototype uses two boards stacked one on top of the other. For production I may design a single board that sticks a little way out the back of the Aquarius (but still much more compact than the mini-expander!).

 

Specifications:-

RAM: 32K static RAM located at the standard address range $4000-$BFFF.

ROM: 512k, banked to emulate up to 64 * 8k ROMs at $E000-$FFFF or 32 * 16k ROMs at $C000-$FFFF.

Sound: AY-8910, may include jack for stereo output.

Joysticks: 20 pin connector for twin joysticks or 16 bits of general purpose I/O.

Storage: FAT file system on USB stick or SD-Card (via CH376S module).

 

ROM bank number is stored in a 74HCT273 8 bit D register, which is loaded by writing to any ROM location between $C000 and $FFFF. The bits are allocated as follows:-

Bits 0 = odd/even 8k ROM number (ignored in 16k ROM mode).

Bits 1-5 = select one of 32 16k ROMs, or (in combination with bit 0) 64 8k ROMs.

Bit 6 = 8k/16k ROM mode.

Bit 7 = lock bit. Setting this to '1' will block any further attempts to modify the bank register.

 

In 8k ROM mode address line A13 is set according to bit 0. The 8k ROM is mirrored at $C000-$DFFF and $E000-$FFFF. In 16k mode A13 is passed through to access the full 16k ROM at $C000-$FFFF. Any combination of 8k and 16k ROMs is possible, so long as the total number of 8k blocks does not exceed 64.

 

The CH376 module will provide access to IBM format files on USB stick or SD Card. It has a fast 8 bit parallel interface and does all the low level stuff internally, requiring minimal resources from the Aquarius to load, save, catalog or delete files. In the prototype it plugs into an external jack at the rear, as there wasn't enough room to mount it internally. Once the design is finalized and surface-mount parts used it may be mounted inside the cartridge.

 

Rather than using two D9 sockets for the joysticks I have gone for a single 20 pin DIL connector. As well as providing access to all of the AY's I/O port bits this will have +5V and Ground to power external devices such as audio DACs, LCD display, wireless joysticks etc. Wired joysticks will be connected via an adapter cable.

 

So far only the 32k RAM part is working, but I hope to test the ROM banking function tomorrow. Once that's done I can work on creating a file system ROM (will probably add it to BLBASIC, which I have already customized to provide some extra BASIC commands).

post-40459-0-31407100-1443090108_thumb.jpg

post-40459-0-23179600-1443090121_thumb.jpg

post-40459-0-27897200-1443090130_thumb.jpg

post-40459-0-39143200-1443090141_thumb.jpg

post-40459-0-99928700-1443090158_thumb.png

post-40459-0-91637900-1443091335_thumb.jpg

Edited by Bruce Abbott
  • Like 12
Link to comment
Share on other sites

ROM part is done!

 

For testing I used a 128k EEPROM which I had recovered from an old PC motherboard. This is large enough to take 8 * 16k ROMs or 16 * 8k ROMs. I had seven 16k ROMs and two 8k ROMs that I wanted to put in it, so they just fitted!

 

On power up the computer boots from BLBASIC, to which I have added a ROM selection menu. I decoupled the reset circuit from the bus so it only activates on power up. Pressing RST on the keyboard will instantly reboot the currently active ROM (to get back to BLBASIC and its ROM selection menu, the power must be cycled).

 

Attached is source code for my modified BLBASIC, and its ROM image (not including the other ROMs). This can be run on the Virtual Aquarius emulator, though selecting other ROMs obviously won't work.

 

EDIT: found a bug in my BLBASIC code (inserting the CALL command caused functions to be offset by one - in() became joy() etc.). ROM and source code updated to V2.1d.

 

post-40459-0-34046100-1443302282_thumb.jpg

post-40459-0-63877200-1443302296_thumb.jpg

post-40459-0-91646400-1443304289_thumb.jpg

BLBasic V21d.bin

BLBasic V21d.asm

Edited by Bruce Abbott
  • Like 4
Link to comment
Share on other sites

Sounding even better now... :)

 

I was concerned that the 'new' AY-3-8910 chip I got off eBay might be a fake (like those 2114 RAM chips I bought that turned out to be LED drivers), but I needn't have worried because it tested out fine and sounds great!

 

Attached is the circuit diagram, and GAL equations for the I/O decoder and address decoder (used on the RAM/ROM board).

 

The main reason I used GALs rather than standard logic chips was to save space. They also have the advantage of being able to change logic functions without having to swap chips or rewire anything. I used Atmel's WinCUPL to design the logic, and a Minipro TL866 to program the GALs.

 

Final step will be to test the CH376, and create commands to read/write/erase and catalog files. I am now disassembling the Quick Disk ROM to see how they process the disk commands...

 

EDIT: missed a couple of resistors on the circuit diagram, now corrected!

 

 

 

 

GALs.zip

post-40459-0-56720100-1443854761_thumb.jpg

post-40459-0-37234400-1443854779_thumb.jpg

post-40459-0-48254900-1443902212_thumb.png

Edited by Bruce Abbott
  • Like 4
Link to comment
Share on other sites

I couldn't find an AY player for the Aquarius, so I ported Vortex Tracker II v1.0 PT3 for the ZX Spectrum by S.V.Bulba (http://bulba.untergrund.net). Eventually I want to get it into ROM with a nice user interface, but for now I have just made a crude version that loads the code into RAM along with the song data.

 

A demo with 4 songs is attached. You can load the .bin file into Virtual Aquarius from the menu 'util/load binary file' with load and execute addresses set to $4000 (It requires 32k RAM, so make sure this option is selected in the memory configuration). After loading, simply type X=USR(X) to start the player. CTRL-C will quit the player if the music gets too annoying!

 

There are two versions of the player - one for PAL machines and one for NTSC. These are required because the player uses the vertical blanking pulse for timing. Since PAL runs at 50Hz and NTSC runs at 60Hz, using the wrong player will cause the music to play 20% too fast or too slow.

 

The binary file can be loaded into a real Aquarius by converting it to wav format. I used AQ_tapeldprep and sent the audio direct to the tape port from my PC. Unfortunately my Aquarius has become very picky about what signals it will accept, so I only managed to load the player once. However I was able to verify that the occasional distortion and hiccups in Virtual Aquarius are an emulator problem - as the songs played perfectly on my machine (and they sound much better in stereo!).

 

EDIT: I just remembered that Virtual Aquarius scrambles the expansion RAM data bus, but doesn't take this into account when loading binary files into it. Please install my BLBASIC ROM (which sets the scramble code to zero) before loading the player, or it will crash!

pt3_demo.zip

Edited by Bruce Abbott
  • Like 5
Link to comment
Share on other sites

Thank you, this helps a great deal. I have limited time to work on robotwon at the moment and this shortcuts a load of audio research :)

 

Finally we are getting some work done in the house next week which means I will be able to finally set up a proper dev workstation,making it easy to work on my little "side projects"

 

Barnie

 

 

 

Some more progress. I managed to squeeze 3 songs and the player into a 16k ROM, with a simple menu and 'graphic effect' (it's just the player's variables stored in color RAM!).

 

 

Edited by barnieg
Link to comment
Share on other sites

  • 2 weeks later...

Wow - I absolutely love reading about this. I will have to load up Virtual Aquarius.

 

When the USB file reader is done what do you think the data transfer rate will be to the Z80? Will you build a path for a file to be buffered directly into memory some how?

 

Thinking about making a great video player for the Aquarius, like truly great, without modifying the primary hardware would have to balance video and audio quality. In many cases I found that I had to waste cycles or lower frame rate simply because the content I had was greater than the 1 MEG of memory that Andrew's ROM card provides.

 

If I had megabytes of storage space and similar data transfer rates (ROM has to be darn near bus speed right?) then the video player could actually be WATCHABLE. Like... we could watch Return of the Jedi, National Lampoon's Vacation, Flashdance, Scarface, War Games, Risky Business, Trading Places, Superman III, A Christmas Story, Easy Money - on the "Computer for the Seventies" released in 1983.

 

If we could figure out a better audio quality using the AY, then maybe we could get like 12 fps flicker, or 24 fps "chase the beam" quality.

 

So you can see why the data rate would matter to me and why it would be great to be able to specify a file to be some how directly loaded to the second bank of the ROM. You could have an 8K program and 8K direct memory access for a source file.

 

Chris

Link to comment
Share on other sites

Wow - I absolutely love reading about this. I will have to load up Virtual Aquarius.

 

When the USB file reader is done what do you think the data transfer rate will be to the Z80? Will you build a path for a file to be buffered directly into memory some how?

Theoretically the CH376 should be able to transfer 200KB/s using INI/OUTI. In practice - we shall see...

I will read the data directly into memory. This is possible because the CH376 works at the file - not sector - level, so block transfer length can be specified down to 1 Byte.

 

If we could figure out a better audio quality using the AY

 

My idea is to attach a simple resistor ladder D/A converter (like the Covox Speech Thing) to one of the joystick ports. You would then have high quality 8 bit audio with minimal overhead. The Aquarius needs 2000 Bytes per frame for full screen video, which at 60fps is 120KB/s. Interleaving a Byte of Audio after every 8 Bytes of video should get a sample rate of ~15kHz.

  • Like 1
Link to comment
Share on other sites

Theoretically the CH376 should be able to transfer 200KB/s using INI/OUTI. In practice - we shall see...

I will read the data directly into memory. This is possible because the CH376 works at the file - not sector - level, so block transfer length can be specified down to 1 Byte.

 

My idea is to attach a simple resistor ladder D/A converter (like the Covox Speech Thing) to one of the joystick ports. You would then have high quality 8 bit audio with minimal overhead. The Aquarius needs 2000 Bytes per frame for full screen video, which at 60fps is 120KB/s. Interleaving a Byte of Audio after every 8 Bytes of video should get a sample rate of ~15kHz.

 

You clearly have a great understanding of this - I am very jealous. Anyway there is this great Viterbi Algorithm encoder for the MSX1 (http://www.msx.org/forum/development/msx-development/crystal-clean-pcm-8bit-samples-poor-psg?page=0) which we know the MSX uses the same sound chip and it is 3 bytes per sample. I realize a D/A converter would sound nice but I love the idea of using the AY. If we have 80 KB/sec for audio then that is 27 KHz at 3 byes per sample, so could get the same. No idea how much of the Z80 it takes to playback the samples though - but has to be a good way to use the AY. :)

Link to comment
Share on other sites

Here's a player for PT2 modules. The demo includes 12 songs. Load and execution address is $3A00.

 

That's enough music programming for now - I need to finish the CH376 driver so I can get it into my Aquarius!

 

 

 

 

 

I can't believe the Aquarius can sing like this. Man - when there is a disk and file storage solution the options feel endless!

  • Like 1
Link to comment
Share on other sites

More progress. I can now load BASIC programs from USB!

 

The file format for a BASIC program is simply a straight memory dump from BASTART to BASEND, which can be extracted from a .CAQ file by removing the 32 byte cassette header (and the 15 byte trailer if you don't want an extra 15 bytes added to the end of the program). I used Hex editor HxD to do this.

 

However I discovered that just loading the file into memory wasn't enough. As well as setting BASTART and BASEND (VARTAB) to the start and end addresses, you must also clear variables/strings/arrays etc. If the program was saved in a different BASIC version then the start address may be different, and all the 'next line' addresses in the program will be wrong. Jumping to the system ROM routine at $0480 fixes all of this, then returns to the BASIC command prompt.

 

Currently I am differentiating between BASIC and BINARY files by whether or not a load address is supplied. My question to anybody who might be interested is: do you think is this enough, or should I use another method to support more file types? Some possibilities I have considered:-

 

1. Use the file extension to determine file type (like MSDOS). Examples:- .BAS = tokenized BASIC file, .CAQ = cassette file (with load address = binary, without load address = BASIC), .TXT = plain text file, .BIN = binary etc. Upside is files can be transferred from a PC without having to convert them to a special format first. Downside is using the wrong extension may confuse the Aquarius.

 

2. As above but also examine the file's contents to determine its type, eg. .CAQ files always start with 12 bytes of $FF. Upside is the correct file extension may not be needed. Downsides are complexity, and a file might be misidentified if it happens to look like another type.

 

3.Add a header to each file which includes the file type, start/end/execute address, internal name etc. This is what Aquarius DOS BASIC does. Upsides are more precise type determination and more information that could be utilized (eg. run a binary executable without having to type in the load and execute address). Downside is yet another specialized Aquarius file format that has to be created on the PC!

BLBASIC-CH376-V21f.zip

Edited by Bruce Abbott
  • Like 2
Link to comment
Share on other sites

 

1. Use the file extension to determine file type (like MSDOS). Examples:- .BAS = tokenized BASIC file, .CAQ = cassette file (with load address = binary, without load address = BASIC), .TXT = plain text file, .BIN = binary etc. Upside is files can be transferred from a PC without having to convert them to a special format first. Downside is using the wrong extension may confuse the Aquarius.

 

2. As above but also examine the file's contents to determine its type, eg. .CAQ files always start with 12 bytes of $FF. Upside is the correct file extension may not be needed. Downsides are complexity, and a file might be misidentified if it happens to look like another type.

 

3.Add a header to each file which includes the file type, start/end/execute address, internal name etc. This is what Aquarius DOS BASIC does. Upsides are more precise type determination and more information that could be utilized (eg. run a binary executable without having to type in the load and execute address). Downside is yet another specialized Aquarius file format that has to be created on the PC!

 

I guess option 1 will do just fine. The only problem I see is that you will always have to know the exact load address for the individual binary files.

Link to comment
Share on other sites

 

The only problem I see is that you will always have to know the exact load address for the individual binary files.

Yes, having to type in the execute address is slightly annoying, particularly since the Aquarius misses keystrokes if you type too fast. I have patched the system ROM to make a click sound on each key press, which helps, but the keyboard response is still slower than I think it should be.

 

I am currently disassembling the system ROM to get a better idea of what the various functions do (required to support file operations such as loading data into an array). Once I understand how it all works I will try developing a UDF hook which replaces the keyboard scanning routine with something better!

 

Attached is my patched system ROM and source code for the patches.

patched_rom.zip

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

 

I am drooling... It loaded incredibly fast. I see that you have some file commands in BL Basic were those part of the disk basic? Can a program access a file? What is the limit to the addressable size???

The command names are from Aquarius disk BASIC, but the code is all new. Files can be loaded from within BASIC using the LOAD command, or from machine code programs by calling the ROM routines directly. I wrote a small BASIC program that loaded the PT2 demo in a loop 100 times. It took 27 seconds, which equates to 110kB/sec.

 

The maximum file size that can be loaded from BASIC is 65535 bytes, but the low level limit is probably around 2GB. Machine code programs can call usb_read_bytes with a smaller size repeatedly until the whole file has been read. At the lowest level you can read individual bytes from the CH376 in up to 256 byte chunks.

  • Like 1
Link to comment
Share on other sites

The command names are from Aquarius disk BASIC, but the code is all new. Files can be loaded from within BASIC using the LOAD command, or from machine code programs by calling the ROM routines directly. I wrote a small BASIC program that loaded the PT2 demo in a loop 100 times. It took 27 seconds, which equates to 110kB/sec.

 

The maximum file size that can be loaded from BASIC is 65535 bytes, but the low level limit is probably around 2GB. Machine code programs can call usb_read_bytes with a smaller size repeatedly until the whole file has been read. At the lowest level you can read individual bytes from the CH376 in up to 256 byte chunks.

 

110 kB/Sec... awesome... how many t-states to pull in a 256 byte chunk? So 110 kB a second would be 440 chunks a second. Let's assume we aren't using your graphics mod (although that opens up a lot of possibilities) and we are using flicker to expand colors. 2000 bytes per 1/2 "frame" or 4000 bytes per frame at 30 Hz flicker and we are at 117k. Hmmmm.... So you would have to run a lower frame rate because we still need bandwidth for sound. We could make it not full screen but you would rather trade frame rate I think. If you flicker each frame 2 times then you get 15 fps and have 60,000 bytes per second for video that leaves plenty of room for audio even at 44.1k and 8 bit.

 

Oh man... we can totally encode an entire movie. Wow... let's pick the movie.

Link to comment
Share on other sites

 

We could make it not full screen

Best not to make it full screen because the first character also affects the border. So the top line is out, and if we remove the bottom line as well for symmetry then that's 160 bytes saved per frame.

 

I would run the sound at 15.734kHz (NTSC horizontal line rate) for an effective 7.8kHz bandwidth. I tried resampling a WAV file to 8 bits at that frequency and it sounded pretty good. My next project is make a D/A converter that plugs into the joystick port, then I will try playing the WAV file on my Aquarius.

  • Like 1
Link to comment
Share on other sites

Good News, Bad News.

 

First the bad news:- the CH376 doesn't double buffer internally, so when reading a file it pauses for up to 2ms before reading each sector. This isn't too much of a problem for video, but wreaks havoc on audio playback. I tried playing a wave file with a fixed delay after reading each sample, but the 0.2~2ms gaps caused the sound to be scratchy and off-pitch.

 

To fill in the gaps I had to read the samples into a buffer at a higher rate, then continue to output samples while waiting for the CH376 to read the next sector. Implementing a circular buffer took up so many CPU cycles that stereo playback at 15kHz was impossible. Since the Aquarius doesn't have a hardware timer I had to count CPU cycles and add different delays for each path in the program - not an easy job :(.

 

Now the good news:- I managed to get it working in mono at 15kHz, and it sounds pretty good!

 

The DAC hardware is a little more complex than I had hoped to get away with. An octal buffer is required (I used a 74HC245) because the AY's I/O ports have weak pullups that affected the accuracy of the R/2R resistor ladder. The circuit is still cheap and relatively simple, though having to wire in the 17 1% resistors was a pain. I have an AD558 which would be more accurate and make life easier, but it is an expensive chip. Another possibility is the TLC7524 (which only costs about $2 in one off quantity).

 

The attached source code plays a raw 8 bit wave file from the CH376 at (approximately) 15Khz. Because the file is read one byte at a time its size is not limited to 64k - the file I used for testing is 6.5MB and plays for over 7 minutes. To convert it from mp3 to raw 8 bit binary I used SoX Sound eXchange. First I converted the mp3 into 15.734 KHz 8 bit mono WAV format (to hear what it sounded like) then I converted from WAV to AFS (raw 8 bit unsigned data). Interestingly the final result was about the same size as the original mp3! SoX 'drag and drop' batch files for doing the conversions are included in the attachment.

 

The attached mp3 is the output from my Aquarius recorded by my PC's sound card. So the original song has gone full circle:- from mp3 to WAV to raw binary, copied to a USB stick and played through a crude DAC on the Aquarius, then re-sampled in WAV format and finally converted back to mp3!

post-40459-0-23824700-1447632398_thumb.jpg

post-40459-0-18910000-1447632460_thumb.png

playwav_src.zip

riders_aq.mp3

Edited by Bruce Abbott
  • Like 5
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...