back to
Section Ensoniq
back to Ensoniq heaven

SQ80 Expansion Project
Trying to reach me?
Expanding the SQ80 is a problem: Its operating system fills up almost all space inside the OSROMs, so if somebody wants to add more features he has to throw out other functions in exchange. But I don't like the idea of "crippling" the SQ80 just for the sake of new functions because it will make it somewhat incompatible to the original machine. Also, people tend to have different opinions about what's not needed... Sad but true... These days one really calls for spam when publishing an email address on a website. But what the heck.

If you expect an answer please send plain text emails. HTML-formatted mails will be dumped automatically.

A possible solution

Looking at the memory map of the SQ80 offers a solution: Examine the I/O space located between $6000 and $6fff - although a 4kB area is reserved for I/O only 254 address locations are really used as the following list shows:
  • $6000 to $60e2 (DOC)
  • $6400 to $640f (DUART)
  • $68f8, $68f0, $68e8, $68d8,  $68b8, $6878 (DAC & Multiplexer)
  • $6c00 (Mapper)
  • $6e00 to $6e03 (FDC)
Since the DAC/Multiplexer decoding is tightly coupled to A7 to A0 it actually occupies a whole page (256 bytes) which leads to the following calculation:

4096 bytes - (248 + 256) bytes = 3592 bytes

3592 bytes of memory space are just wasted due to improper address decoding! Of course quite a tricky decoding is needed to implant additional ROM into this area since the I/O areas have to be kept separated - but today, where PALs and CPLDs are quite cheap that's no issue.

But we aren't limited to a single 4kB area - we easily can have 64kB (or if needed up to 512kB) of additional ROM. How? Keep in mind that the Mapper only uses Bit 0, the Bits 7 to 1 are free for use and can be connected to the upper address lines of bigger EPROMs such as 27512 and above. Just look at the following schematics:


As you can see, the bit pattern can be read back - and it has to be, since only through that mechanism one can do independent manipulation of each control bit without keeping the pattern stored somewhere in RAM (which would cause interference with the original ROM routines). Now I hear you cry, that this new Mapper would be incompatible to the original one - and you are right. But luckily we have enough unused storage area in ROMHIGH which can hold replacement routines which can be used instead of the original "STA $6c00". The area I'm speaking of is $ffa4 to $ffdf offering 60 bytes of free memory.  Fortunately a "JSR address" occupies the same space the STA command does so we easily can patch the ROM to access the following routines:

mapseq   PSHS A,CC    ; rescue A
         LDA $6C00    ; get bit pattern
         ORA #$01     ; map SEQRAM
         BRA eomap    ; saves 3 bytes :)

mapdos   PSHS A,CC    ; rescue A
         LDA $6C00    ; get bit pattern
         ANDA #$FE    ; map DOSRAM
eomap    STA $6C00
         PULS PC,CC,A ; rescue registers

This takes 21 bytes, so we have another 39 bytes left. These we can use for a bankswitching routine for accessing multiple 4kB blocks. Having a single output multiplexer in mind I reserve bits 7 to 5 for audio channel multiplexing and only use bits 4 to 1 for ROM block multiplexing:
page4k   PSHS A,CC    ; page number to stack
         LDA $6C00    ; get bit pattern
         ANDA #$E1    ; keep mapper & audio mux bits
         BRA eopage   ; saves 1 byte :)

audiochn PSHS A,CC    ; channel number to stack
         LDA $6C00    ; get bit pattern
         ANDA #$1F    ; keep mapper & ROM mux bits
eopage   ORA ,S+      ; merge in new mux pattern
         PULS PC,CC

These routines use another 20 bytes so we still have 19 bytes left - try to do that in PASCAL... 

What can we do with this additional space? Well, I think of the following:

  • DOS routines giving the SQ80 the ability to read and write the world's most famous file system
  • Single channel outputs
  • Master Keyboard abilities
  • New, bigger & better OS :)

Now, the ROM itself will have a funny layout since it can be only used in the non-overlapping areas, so the following areas of each 4kB section have to be left out:
  • $0000 to $00E2 (occupied by DOC)
  • $0400 to $040F (occupied by DUART)
  • $0800 to $08FF (occupied by DAC/MUX)
  • $0C00 (occupied by Mapper)
  • $0E00 to $0E03 (occupied by FDC)
If you are writing programs for this ROM area you have to take care that your code doesn't range into these "forbidden" zones and you might have to manoeuver around these by BRA.