Rocky Gush Floppy Drive Interface

edited May 2013 in Hardware
I have a Rocky Gush Floppy Drive Interface which I would like to post the details under the Hardware section of the website. What is correct procedure to post the details? Rocky Gush is from South Africa and designed and manufactured the interfaces locally during the mid-80's.

You could connect four double sided drives to the interface. It also has a printer interface for a Centronics EPSON compatible printer. The interface also has a NMI button which will dump the current state (Software which is running or program listing) directly to the disk. I also have the original manual in txt format. Rocky also promised me that he will scan a magazine with the interface in and email it to me.

He designed the PCB of the interface with a program called DUMBWORK in deference to the PC package SMARTWORK. He build a plotter with a drum from a tele-printer platen roller and plotted the PCB layout for manufacturing.

I would like to add images to this post, but when I press the Insert Image button, it asks for a URL of the image. What is the correct way to add images to a post?

Pierre
Post edited by Pierre on
«1

Comments

  • edited March 2013
    Information about hardware is always very welcome.

    If you contact martijn or submit material via upload form it should get added to the hardware database.

    The Hardware Page is run by someone else and was last updated in 2010 so I don't know how up to date/active that project is.

    If you have lots of technical info like schematics and specifications you might want to add an article on the SinclairFAQ Wiki. (I'll keep flogging that particular horse until people start contributing articles :lol:)

    You can't attach images to the forum, but if you upload them somewhere else you can embed them with [noparse]image.jpg[/noparse]image.jpgimage.jpg
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • edited March 2013
    Hi

    Thanks for the reply. My interface broke some time ago when it fell of a table while still plugged into the Spectrum. I contacted Rocky after more than 20 years, but he did not have the circuit diagrams or PCB layouts anymore. Rocky then gave me permission to rebuild a duplicate interface. I then took it to task to redraw the circuit diagram and PCB layout to rebuild my interface. I had a duplicate PCB manufactured and assembled the interface last week. I only finished with it this weekend and everything is working correctly. Rocky gave me permission to post pictures and info on the website, but I did not ask him for permission for posting the circuit diagrams and PCB layout. I will contact him first before I upload the circuit diagrams and PCB layout.

    Pierre
  • edited March 2013
    Good news. I contacted Rocky and he gave permission to upload all info, including circuit diagrams, PCB layout, ROM dumps, etc. I will try do it tomorrow.

    Pierre
  • edited March 2013
    That will certainly be very interesting to see!
    No one important.
  • edited March 2013
    Don?t forget to included the O.S. file of the ROM, (maybe an EPROM).
  • edited March 2013
    I am not sure how to do the uploading, as the upload page seems for cassettes. There is only one attachment field. Do I use the same page for hardware uploads and how do I attach more than one file, for example the pictures, PCB layout, circuit diagram, EPROM files, etc?

    Pierre
  • edited March 2013
    I have been unable to get a reply sofar with regards to the uploading of the info to the WOS website. I have however uploaded the files to another server so that it can be viewed in this forum:

    Picture of original interface (Now dead)
    IMG_4228.JPG

    Picture of my board after manufacturing (I made a copy of the original board)
    IMG_4825.JPG

    Picture of my board with components (I did not add the outgoing edge connector yet - that is to connect other devices)
    IMG_4846.JPG

    Picture of boot-up screen (quality not good due to a camera picture of old B&W TV)
    IMG_4854.JPG

    Picture of files stored on disk
    IMG_4855.JPG

    User Manual of Interface : http://www.del-com.co.za/rockygush/Rocky Gush User Manual.txt

    EPROM Binary File for ULA ROM : http://www.del-com.co.za/rockygush/Rocky Gush ULA EPROM.BIN

    EPROM Binary File for DOSROM : http://www.del-com.co.za/rockygush/Rocky Gush DOS EPROM.BIN

    Schematic : http://www.del-com.co.za/rockygush/Rocky Gush Schematic.pdf

    PCB top layer : http://www.del-com.co.za/rockygush/Rocky Gush PCB Top Layer.pdf

    PCB bottomlayer : http://www.del-com.co.za/rockygush/Rocky Gush PCB Bottom Layer.pdf
  • zubzub
    edited March 2013
    Pierre wrote: »

    Ooh — it uses a WD FD1791! I might have a go at this, if I can follow the schematic. :-)

    I'm puzzled by the signal that's labelled /MI. Should that be /M1, instead?

    Also, I don't quite get '/ROMCS - OUT' and '/A14 - OUT'... is that for edge connector pass-through, or something else?

    The separate 'ULA' ROM and 'DOS' ROM images seem puzzling.

    The action of SW1 and SW2 baffles me slightly. I can see from the manual that they're 'enable DOS' and 'IF1 attached' switches, and they seem to inhibit the device to an extent... I can see that the output from these switches ultimately affects CE of the 2764 (the 64 KiB EPROM, i.e. 'DOS' ROM)... but then looking at the 'ULA' ROM, I find that it really does seem to be wired up in the strangest way! Its output seems to feed straight into the 74LS175 latch, and the outputs of that feed into various logic gates at least involving paging of the DOS ROM.

    So it seems to me that the ULA ROM is exactly what it claims to be, and actually contains a bitmask of actions that should be carried out upon execution by the CPU of different addresses in the Sinclair ROM. This seems quite ingenious to me, although perhaps it was a common technique? I guess for larger-scale manufacture, you might go for a real ULA, or you might also use a PAL or two... but I guess PALs are somewhat limited in the complexity of their logic, whereas using a ROM image allows arbitrary behaviour for each of the 16/48K Spectrum ROM's 16384 memory locations (although not all will be an initial byte of an instruction).

    A hex dump of the ULA PAL seems to pretty much confirm my understanding:
    0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    2000 bf ff ff ff ff ff ff ff 7f ff ff ff ff ff ef ff
    2010 ff ff ff ff ff ff bf ff ff ff ff ff ff ff ff ff
    2020 ff ff ef ff ff ff ff ff ff ff ff ff ff ff ff ff
    2030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    2040 ff ff ff ff ff ff ff ff ef ff ff ff ff ff ff ff
    2050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    2060 ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
    2070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    2280 ef ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    2290 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    24c0 ff ff ef ff ff ff ff ff ff ff ff ff ff ff ff ff
    24d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    2550 ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
    2560 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    2700 df ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    2710 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    2970 ef ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    2980 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    29f0 ff ff ff ff ef ff ff ff ff ff ff ff ff ff ff ff
    2a00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    31c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff df ff
    31d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    3290 ff ff ef ff ff ff ff ff ff ff ff ff ff ff ff ff
    32a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    3370 ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
    3380 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    36e0 ef ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    36f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    3700 ff ff ff ff ff ff ff ff 7f ff ff ff ff ff ff ff
    3710 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    3b40 ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
    3b50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    3fd0 ff ff ff ff ff ff ff ff ff ff ff ff ef ff ff ff
    3fe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    *
    4000
    
    (* means 'ditto').
    

    Only bits 4, 5, 6 and 7 are ever clear, and in fact, only one of them at a time is ever low in any one byte, so the low nibble is always 0xf, and the high nibble is always 0xf, 0xe (i.e. 0xf−1), 0xd (i.e. 0xf−2), 0xb (i.e. 0xf−4) or 7 (i.e. 0xf−8).

    This seems to specify one of four actions at twenty different addresses.

    Now to figure out what's at those addresses in the ROM!
    2000 bf --> ^D1
    2008 7f --------------> ^D4
    200e ef ------> ^D2
    2016 bf --> ^D1
    2022 ef ------> ^D2
    2048 ef ------> ^D2
    2066 ef ------> ^D2
    2280 ef ------> ^D2
    24c2 ef ------> ^D2
    2556 ef ------> ^D2
    2700 df ----------> ^D3
    2970 ef ------> ^D2
    29f4 ef ------> ^D2
    31ce df ----------> ^D3
    3292 ef ------> ^D2
    3376 ef ------> ^D2
    36e0 ef ------> ^D2
    3708 7f --------------> ^D4
    3b46 ef -----> ^D2
    3fdc ef -----> ^D2
    

    The addresses seem a little unusual, though, as they're all in the upper half of the ROM.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited March 2013
    zub wrote: »
    The addresses seem a little unusual, though, as they're all in the upper half of the ROM.

    On closer examination, I see that A13 of the 27128 (U13) is always high, and that the logic that feeds into its /CE most involves A13 thanks to U4 (one of the 74LS138 1-of-8 decoders). U4 seems to also pull in A12 and A15 as inputs, but it is only enabled if /MREQ is low (i.e. a memory request is in progress), A14 is low (i.e. we're in the low 32 KiB of address space) and '/ROMCS ? OUT' is high (i.e. another peripheral doesn't already have its own ROM paged in). Since /Y4, /Y5, /Y6 and /Y7 are unconnected, A2 effectively acts as though it were an extra '/E4' line ? that is to say, it must be low for any of the connected outputs of U4 to be low. The U4's A2 comes from the Spectrum bus's A15, so this is expected, as we're only interested in addresses between 0x0000 and 0x3fff (since that's where the Spectrum ROM resides).

    If A13 from the Spectrum bus (A1 of U4) is high, then the action of the decoders means that /Y0 and /Y1 will remain high (i.e. inactive)... but in that case /Y2 or /Y3 will be active (low) depending on A12 (from the Spectrum bus).

    If /Y3 is low, then an address from 0x3000?0x3fff is being accessed, so the 6264 RAM's chip selected line is activated. I don't quite follow this, but it seems there's also logic for presenting other peripherals with an A14 that is pulled high whilst the FloppyOne's RAM is being accessed, presumably to avoid any danger of accidental modification of the contents of the RAM of other peripherals.

    If /Y2 is low, then an address from 0x2000?0x2fff is being accessed. /Y2 feeds in the /E1 enable line of U5. /E2 of U5 seems to be connected to a paging flip-flop, and E3 to the Spectrum bus's A2 line. By means of unconnected outputs, /RD and /WR are monitored, with different outputs selected depending on the Spectrum bus's A3 line. The outputs of U5 seems to feed in to U11 (the 74LS164 serial shift register used for parallel printer output), a select line for the printer busy status bit, the printer strobe line, and the clock of U8, a 74LS174 D-type flip-flop, which seems to be used for controlling the drive selection, side selection and 'motor on' outputs.

    So, it would seem that the FloppyOne has ROM from 0x0000?0x1fff, RAM from 0x3000?0x3fff, but uses MMIO from 0x2000?0x2fff for control of the interface, whereas most other interfaces would use port I/O, instead.

    MMIO addresses with A2 low (0x2000?0x2003, 0x2008?0x200f, ..., 0x2ff8?0x2ffb.) provide access to the FD1791 registers, with A0 and A1 wired straight from the Spectrum's bus to the same lines of the FD1791.

    MMIO addresses with A2 high and A3 low (0x2004?0x2007, 0x2014?0x2017, ..., 0x2ff4?0x2ff7) provide printer busy status in D5 when reading, and printer output taken from D7 when writing. With A2 high and A3 low, (0x200c?0x200f, 0x201c?0x201f, ..., 0x2ffc?0x2fff), reading lowers the printer strobe line briefly, whereas writing accesses the floppy control port, with the drive selection bits in D0?D3 (with D0 for drive 0, D1 for drive 1, D2 for drive 2, D3 for drive 3) and 'motor on' control affected by D5 (and it seems also the FD1791).

    I still don't fully understand the paging logic, and am not sure if I ever will... but if nobody tries in the next week or so, I might give this a go!

    Oh my goodness... I'm actually reading hardware schematics and possibly understanding them (or at least bits of them). How did this happen?! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    zub wrote: »
    I still don't fully understand the paging logic, and am not sure if I ever will... but if nobody tries in the next week or so, I might give this a go!

    So I guess it won't make v1.1 then? Better target it for v1.2 ;)
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • zubzub
    edited March 2013
    guesser wrote: »
    So I guess it won't make v1.1 then? Better target it for v1.2 ;)

    Yep! :-)

    Neither would the half-finished TK 90X/TK 95, ?Speech, ?Source, Soundrive/Covox, SoftROM, SAM Messenger, Mirage Microdriver, SoftROM or SAM Coup? emulation... and neither would support for loading SC_Speclone / SAM Messenger snapshots. Needless to say, when we switch to Git, I'm looking forward to the better handling of branches...

    ... *ahem* but back on topic... since the FloppyOne is built out of discrete logic (admittedly with this rather fabulous 'ULA' ROM), it would probably be best to try to understand that logic, rather than to make guesses based on disassembling the code... so I'm some way from being able to write code to emulate it!

    In any case, if we just end up with a description of how the hardware behaves from a software PoV, that's perhaps not such a bad thing to have.

    I imagine anyone wanting to make more FloppyOnes would perhaps think about moving away from the 'ULA' ROM + lots of discrete logic and use a CPLD(?) instead?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited March 2013
    zub wrote: »
    I don't quite follow this, but it seems there's also logic for presenting other peripherals with an A14 that is pulled high whilst the FloppyOne's RAM is being accessed, presumably to avoid any danger of accidental modification of the contents of the RAM of other peripherals.

    Ah, apologies for my confusion. I now see the diode between U3's NAND gate leading to 'A14 ? OUT' and U4. :-)

    So, 'A14 ? OUT' is high whenever the interface is paged in, but /CS1 of the 6264 RAM would be low for accesses from 0x3000?0x3fff, but is pulled high if the FloppyOne RAM/MMIO is paged out.

    It certainly seems that paging of the 'DOS' ROM and paging of the RAM/MMIO are linked but not quite handled identically.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    Thanks for all the feedback. I did not design the interface; I only copied it because mine was broken. I got permission from the designer (Rocky Gush) to copy it and to post the detail on the Forum. The ROM does not include the Spectrum DOS, only the disk drive DOS, and the ULA EPROM is used to switch the DOS ROM in and out when needed for the DOS command. SW1 is used to either enable or disable the interface and SW2 must be on if an Interface 1 is used with the Disk Interface. The two out line is going to the back edge connector where you can connect the Interface 1 or joystick interface, etc. You will also see that the VCC of the 74LS164 shift register (U11) is connected via a LED. I asked Rocky about it and he told me that the Chip was switching the data to fast, causing data corruption. When the supply voltage is dropped with the LED, the shift register switch slower and hence the mod.

    You are right about the /MI., which should that be /M1. It is the funny font of the schematic package that I used. Also read the user manual. Rocky has some machine code examples in it.

    Remember the intarfece is just about 30 years old
  • edited March 2013
    zub wrote: »
    So it seems to me that the ULA ROM is exactly what it claims to be, and actually contains a bitmask of actions that should be carried out upon execution by the CPU of different addresses in the Sinclair ROM. This seems quite ingenious to me, although perhaps it was a common technique?

    The tense should be present here, "is" rather than "was" :-) Effectively the ROM here is a giant lookup table.

    Inside a modern FPGA the same technique is used to form combinatorial logic. Instead of (for example) having a bunch of gates and programmable interconnects between them, each configurable logic block in an FPGA has a small look up table which when it boils down to it, is just RAM. Usually each logic block has a 16 bit lookup table for implementing combinatorial logic. If you think about it, there's no difference between using actual logic gates themselves and a lookup table that has the truth table for the logic function.

    This "ULA ROM" is just a very large lookup table. It was probably easier and less expensive to implement the number of address decodes by using a memory IC instead of actual discrete logic or PAL/GAL chips.
  • zubzub
    edited March 2013
    Pierre wrote: »
    Thanks for all the feedback. I did not design the interface; I only copied it because mine was broken. I got permission from the designer (Rocky Gush) to copy it and to post the detail on the Forum.

    Yeah, I realise ? but as you said, you were able to build a duplicate interface, and there are also others on the forums who might be able to answer my silly questions. :-)
    The ROM does not include the Spectrum DOS, only the disk drive DOS, and the ULA EPROM is used to switch the DOS ROM in and out when needed for the DOS command.

    Spectrum DOS? I'm not sure I follow you. Regarding the 'ULA' ROM, I was remarking on the fact that its memory contents relate closely to those of the Spectrum ROM (and perhaps the IF1 ROM). It has bits clear at certain addresses in the other ROMs at which to page in or page out the interface.
    SW1 is used to either enable or disable the interface and SW2 must be on if an Interface 1 is used with the Disk Interface. The two out line is going to the back edge connector where you can connect the Interface 1 or joystick interface, etc.

    I'm not sure what 'on' means in this context. It looks to me as if SW2 is closed, the device won't automatically be paged in, and that if SW1 is open, it will be paged out upon execution of certain IF1-related addresses. I still don't quite follow the precise detail of this, and testing it might be tricky... but I can perhaps try if nobody else can explain!
    You will also see that the VCC of the 74LS164 shift register (U11) is connected via a LED. I asked Rocky about it and he told me that the Chip was switching the data to fast, causing data corruption. When the supply voltage is dropped with the LED, the shift register switch slower and hence the mod.

    Helpful to know for anyone building a replica!
    You are right about the /MI., which should that be /M1. It is the funny font of the schematic package that I used. Also read the user manual. Rocky has some machine code examples in it.

    Thanks! I see that it confirms what I've said (or rather, I've confirmed what it says) about returning the printer busy status in bit 5 of 0x2004 (high=>busy, low=>not busy), and that RAM is at 0x3000 and ROM at 0x0000... but that's about all I can see. Still, very useful to have the manual!

    Do you have a scanned copy of the manual that I could use for proof-reading, at all? I've noticed a missing word or two in the manual and am wondering if the original is affected.

    BTW, it looks like it's not the font of the package that's causing the issue. Zooming right in on '/MI' and on '/NMI' and 'A1' reveals that the 'I' glyph is being used, not the '1' glyph, so it should be possible to correct it.
    Remember the interface is just about 30 years old

    Yep! ... but then the DISCiPLE, which we've been figuring out the last few details of, is hardly new either! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    As to my mistake with to term "Spectrum DOS", this is completely wrong. I meant the Spectrum Basic ROM. I wrote the reply in a hurry while I was on my way out and my home language is unfortunately not English, thus the incorrect grammar, spelling and misguided info sometimes.

    What I meant by the SW1 and 2 "on" is actually that they must be in the closed position.

    If anybody would like to build a replica, I created Gerber files to have the PCB manufactured. I also found that you must use74LS chips and not 74HC?s or else most of the logic circuits do not work correctly. This was the first time in more than 17 years that I worked on an electronic project on component level.

    The user manual I got from Rocky in a TXT format. I will ask him if he has it in another format. I know when I purchased the original interface during the middle 80?s, I got a disk from him with the manual on and a version of TASWORD and TASPRINT that worked with his Centronics printer interface. That disk is however long gone.

    I will ask Rocky if he will be willing to join the forum, if there are any detail questions that arise. I would however respect his privacy if he does not want to.

    I must admit that I enjoyed the project and also the exposure that it is getting through the forum. I am a great believer that interfaces like that should be preserved somehow.

    Pierre
  • edited March 2013
    Pierre wrote: »
    If anybody would like to build a replica, I created Gerber files to have the PCB manufactured. I also found that you must use74LS chips and not 74HC?s or else most of the logic circuits do not work correctly.

    How about 74HCT? If it's just a question of levels, then 74HCT is TTL compatible and currently manufactured.
  • edited March 2013
    Hi Winston

    Thanks for that. Yes I did consider that, but the 74LS range is availably very cheaply locally in Cape Town. I just had some HC's lying around which I tried. I actually had the same problems with the EPROM's, where the 27C128 and 27C64 did not want to work and I had to use 27128 and 2764 as the original.

    Pierre
  • zubzub
    edited March 2013
    Winston wrote: »
    The tense should be present here, "is" rather than "was" :-) Effectively the ROM here is a giant lookup table.

    Inside a modern FPGA the same technique is used to form combinatorial logic. Instead of (for example) having a bunch of gates and programmable interconnects between them, each configurable logic block in an FPGA has a small look up table which when it boils down to it, is just RAM. Usually each logic block has a 16 bit lookup table for implementing combinatorial logic. If you think about it, there's no difference between using actual logic gates themselves and a lookup table that has the truth table for the logic function.

    This "ULA ROM" is just a very large lookup table. It was probably easier and less expensive to implement the number of address decodes by using a memory IC instead of actual discrete logic or PAL/GAL chips.

    I'd realised that all programmable logic was somewhat akin to what I was describing, although it's interesting to read your description of 16-bit lookup tables. By that, do you mean tables with 65,536 entries? If so, then yes, that really isn't too different! Either way, I was rather struck by the size of the ROM (half of which is unused) compared to the complexity of the logic that it contains: 13 inputs, 4 outputs, and only 20 combinations. I'm not sure how well this would fit into PALs at the time, but 16 KiB seems like quite a lot for this task ? although actually, 8 KiB would been fine. I do wonder, as to use a 16 KiB EPROM and leave half of it blank seems to me as though it would have been quite excessive in the mid-1980s.

    I was also a little startled by the use of an actual ROM rather than a logic device that uses a ROM to determine its behaviour at a gate level. Perhaps this is/was more common than I realise, especially for those that might not have had PAL programmers (although Rocky Gush seems to have run half of .za's tech industry from the looks of things!) or where the logic was a little too complex for a single PAL.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    16 bits as in two bytes. The lookup table (LUT) in each configurable logic block of a Xilinx Spartan-3 has a 4 input LUT if I remember correctly, which means 16 bits of memory (each CLB is very small, basically each CLB will have something like a 4 input LUT, a flip flop and a multiplexer - the datasheet for the chip describes it exactly, I might not be remembering the CLB's features exactly). The Spartan-6 has 6 input LUTs if I remember correctly (so 64 bits per LUT). The CLB is the smallest unit of logic, and they are grouped into "slices" (a small group of CLBs).
  • edited March 2013
    A question, Do you have the gerbler files for make the PCB?, many thanks.
  • edited March 2013
    Hi

    I do have the Gerber files, but if more people are interested, then I could get a batch of 10 made. I already had another guy who contacted me and wants a PCB. They will work out roughly $3 per board, but I will have to confirm this with the manufacturer. The manufacturer is in China and I only found out about it over the weekend. The board that I had made was locally in South Africa and cost me $55 for the one prototype.

    Regards
    Pierre
  • edited March 2013
    Ok, if you get PCB?s for $3 i want 2 or 3, any way if is possible, can do you send me the gerber files?, many thanks for you great work.
  • edited March 2013
    Hi Flopping

    Apologies for only doing the post now, but I was away on holiday for a few days. I checked with the PCB supplier and the price of $3 per board is for a 1 dm board, but it must be 10cn x 10 cm. The Gush board is 12cm x 8cm and because of the dimensions I must pay for a 10cm x 15Cm board, which will work out at $6 and I must purchase a minimum of 10. I think it will be better for you to get one made locally. The Gerber file is at the link as below. I zipped them into one file to make the download easier. Let me know when you want to start your assemble so that I can give you the component layout.

    http://www.del-com.co.za/rockygush/PCB and Schematic.zip

    Regards
    Pierre
  • edited March 2013
    Ok Pierre, many thanks.
  • JmkJmk
    edited April 2013
    I've been looking into this as well, but by reverse engineering, rather than hardware schematics (I just can't read anything beyond really simple ones).

    My findings match your memory-mapped addresses, with the addition of Bit 4 of $200C being Side Select (0 = Side 1, 1 = Side 2).

    Your list of trap addresses (mostly) makes sense if you mask off the $2000 and convert them to $0000-$1FFF addresses.

    The process seems to be:
    Fetch first byte of instruction
    Page ROM
    Fetch any further bytes
    Execute instruction

    ...which could lead to some odd mixed ROM instructions, but mostly it's fine.

    The ones marked D1 are for paging out the RG ROM and going into the 48 ROM.
    D2 are for moving from 48 ROM to RG ROM.
    D3 and D4 I'm not sure about, but the D4 ones match the traps you'd use to page in the IF1 ROM and one of the D3 ones ($0700) matches the trap you'd use to page out the IF1 ROM.

    The RET at $0280 is interesting as it's actually <> in the SYM_CODES list, but is used by various RG routines to return from a call to the 48 ROM.
    Geoff Wearmouth's 48 BASIC ROM disassembly

    One exception, I haven't figured out the D2 $0022 trap. It's the last byte of CALL $0074!

    Emulation-wise, I've got the interface running (including the 64-column chars), but not the disk access. It uses a lot of unusual waits for the BUSY flag which my poor FDC emulation can't handle.

    The drive detection routine at $0F2A-$0FE4 is a right pain! I can hack my way past that, but I end up with a lot of "No disc in drive !"

    If anyone can figure out what is supposed to be happening with the FDC there, I'd be grateful!
  • zubzub
    edited April 2013
    Jmk wrote: »
    I've been looking into this as well, but by reverse engineering, rather than hardware schematics (I just can't read anything beyond really simple ones).

    I thought I couldn't too, until I gave it a go! I'll admit, the use of pull-up and pull-down resistors with the flip-flops in Rocky Gush's FloppyOne interface still confuses me... but most of it isn't that hard. Once you look at the datasheets of the various ICs (latches, multiplexors and shift registers, mainly), it's quite simple.

    I'd recommend that you read Chris Smith's book on the Spectrum ULA if you're interested. Much of it doesn't require an in-depth understanding of hardware (you can skip the chapters on general silicon chip and Ferranti ULA fabrication processes if you want), and since it's in the context of the Spectrum, I found it to be something that could grab my attention and hold onto it quite easily. :-)
    My findings match your memory-mapped addresses, with the addition of Bit 4 of $200C being Side Select (0 = Side 1, 1 = Side 2).

    Oops — I don't know how I managed to miss that out! I did mention side selection along with drive selection, but forgot to mention this in detailing the port I/O. I'll admit that I wasn't quite sure whether 'Side 1' would be a logic '0' or a logic '1' (it's a logic '0'), though. Thank-you for pointing this out!
    Your list of trap addresses (mostly) makes sense if you mask off the $2000 and convert them to $0000-$1FFF addresses.

    Apologies, I should have made that clearer. This is what I meant when I said:
    zub wrote: »
    On closer examination, I see that A13 of the 27128 (U13) is always high, and that the logic that feeds into its /CE most involves A13 thanks to U4 (one of the 74LS138 1-of-8 decoders)

    What I mean by this is that A13 of the 'ULA ROM' (and note that this 'ULA' ROM has nothing whatsoever to do with the Spectrum ULA) has A13 permanently set as a logic '1', meaning that only addresses $2000–$3FFF within the ROM can ever be accessed. The second part of my sentence refers to the circumstances in which the 'ULA ROM' will be active. Its 'chip enable' (/CE) line is only ever high if A13 on the Spectrum bus (i.e. from the Z80) is low, meaning that it will only trap addresses $0000–$1FFF and will not trap execution at $2000–$3FFF.

    A13 isn't the sole input to the /CE line of the 'ULA ROM', since we also need to consider the Z80's 'M1 cycle active' line (for those that don't know, the Z80's M1 cycle is the first cycle of each instruction, which is the cycle in which the instruction's opcode is fetched), and also A14 and A15 (to ensure together with A13 that an address between $0000–$1FFF is being accessed, rather than $4000–$5FFF, $8000–$9FFF or $C000–$DFFF). The signal that feeds the /CE of the 'ULA ROM' is also used as the clock signal for the chip that uses its output, meaning that the 'ULA ROM's output is only ever taken when the 'ULA ROM' is actually being accessed (during execution at addresses $0000–$1FFF).
    The process seems to be:
    Fetch first byte of instruction
    Page ROM
    Fetch any further bytes
    Execute instruction

    I guess you're saying that the paging logic is too slow for the first byte of the instruction that is fetched to come from the 'DOS ROM'?

    I might have expected the 'DOS ROM' to contain the same first byte as the Spectrum ROM in this case, although presumably you've found that this is not the case?

    I've seen that other devices place the same instruction (or at least the same opcode byte) in their ROM as is in the corresponding area in the Spectrum ROM at the point where the device's ROM is paged in/out, as a means of ensuring that any delay affecting the paging would not cause different instructions to be executed... but not all devices do this.
    ...which could lead to some odd mixed ROM instructions, but mostly it's fine.

    Mostly? I suppose this might be done intentionally is some places, as it would be safe to assume that paging has stabilised when fetching the next byte after the address which was trapped.
    The ones marked D1 are for paging out the RG ROM and going into the 48 ROM.
    D2 are for moving from 48 ROM to RG ROM.
    D3 and D4 I'm not sure about, but the D4 ones match the traps you'd use to page in the IF1 ROM and one of the D3 ones ($0700) matches the trap you'd use to page out the IF1 ROM.

    I can well believe that. The Q1 and Q2 outputs of U12 (at 74LS175, which is apparently a quad D-type flip-flop) which correspond to the D1 and D2 inputs obtained from the 'ULA ROM' (bits 4 and 6, respectively) seem to be connected to the 'main part' of the paging circuitry, near the top of the diagram. The flip-flop that they feed into is used as an input to a NAND gate which controls the chip select line (/CE) of the 'DOS ROM'.

    The Q3 and Q4 outputs (which correspond to the D3 and D4 inputs from the 'ULA ROM', bits 5 and 7 respectively) on the other hand, feed into what appears to be a secondary flip-flop, which itself feeds into the same flip-flop as the Q1 and Q2 outputs.

    To be honest, I wasn't going to worry about understanding the full detail of the schematic in this regard, but was assuming that the D3 and D4 inputs just related to extra paging required for IF1 compatibility. If it turned out that I was mistaken, and that the paging had to be disabled for the IF1, I'd have reversed the paging logic and examined the effect on emulation.
    The RET at $0280 is interesting as it's actually <> in the SYM_CODES list, but is used by various RG routines to return from a call to the 48 ROM.
    Geoff Wearmouth's 48 BASIC ROM disassembly

    Ouch. I can imagine there's roughly 0.000000% chance of this working on many of clones — especially those with modified ROMs. I would imagine that the locations of symbols within SYM_CODES are somewhat different on the TK 90X and TK 95, for example. Then again, the sheer number of addresses that are trapped by the FloppyOne would make compatibility an issue, probably even with the OpenSE ROM.
    One exception, I haven't figured out the D2 $0022 trap. It's the last byte of CALL $0074!

    Intentional somehow? Testing purposes? I'm confused...

    For those that are wondering, the confusion here is that it affects the last byte of an instruction, i.e. at a point where M1 will not be active. So for this to take effect, you'd have to jump to that last byte of the instruction directly, as though it were the first byte of an instruction. The byte at this address is $00 (since CALL $0074 assembled as $CD, $74, $00), which is the opcode for a NOP instruction.
    Emulation-wise, I've got the interface running (including the 64-column chars), but not the disk access. It uses a lot of unusual waits for the BUSY flag which my poor FDC emulation can't handle.

    The drive detection routine at $0F2A-$0FE4 is a right pain! I can hack my way past that, but I end up with a lot of "No disc in drive !"

    If anyone can figure out what is supposed to be happening with the FDC there, I'd be grateful!

    Excellent! I'm afraid I can't help much just at the moment, as I'll have to get Fuse into a similar position before I can experiment much, and I've been unable to find time to help get the 1.1 release out just lately... but hopefully it's a matter of modelling the timing of the FDC accurately, for which the datasheet should be of some use. Fuse's emulation is also likely to be poor in this respect (since it never needed to emulate FDC timings accurately), although I haven't looked in detail.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • JmkJmk
    edited April 2013
    zub wrote: »
    I'd recommend that you read Chris Smith's book on the Spectrum ULA if you're interested. Much of it doesn't require an in-depth understanding of hardware (you can skip the chapters on general silicon chip and Ferranti ULA fabrication processes if you want), and since it's in the context of the Spectrum, I found it to be something that could grab my attention and hold onto it quite easily. :-)

    And since I have it on the shelf here, I should've read those sections in more detail!
    Oops ? I don't know how I managed to miss that out! I did mention side selection along with drive selection, but forgot to mention this in detailing the port I/O. I'll admit that I wasn't quite sure whether 'Side 1' would be a logic '0' or a logic '1' (it's a logic '0'), though. Thank-you for pointing this out!

    There is a degree of assumption on my part... When you access "drives" 1-4 the bit is 0 and when you access "drives" 5-8 the bit is 1. I have a disk image from Pierre which would confirm it... if I could get the drive access to work!
    I guess you're saying that the paging logic is too slow for the first byte of the instruction that is fetched to come from the 'DOS ROM'?

    I might have expected the 'DOS ROM' to contain the same first byte as the Spectrum ROM in this case, although presumably you've found that this is not the case?

    Intentional somehow? Testing purposes? I'm confused...

    In the case of $0016 (returning from RG ROM to 48 ROM), you get a RET in the RG ROM and RST $38 in the 48 ROM. RET is certainly the correct one. The same applies to the $0280 (48 ROM to RG ROM) RET (which is $F9 in the middle of an instruction in the RG ROM).

    For most of the multibyte instruction traps, the first byte is the same while the others can be different.

    $1FDC is an odd one.

    48 (part of PRINT-1):
    1FDB CALL $1BEE ($CD $EE $1B)

    RG:
    1FDB RST $38 ($FF)
    1FDC XOR $1B ($EE $1B)

    Could it be performing the paging after fetching the 2nd byte of the instruction?
  • edited May 2013
    Hi Pierre, i will go to start to assemble the Rocky gush floppy drive interface, and i ask me if you can give me the component layout of the PCB?, many thanks for your help.
  • edited May 2013
    Hi

    I am just a little bit out of time today. I will try to draw it out tomorrow and email it to you.

    Pierre
Sign In or Register to comment.