The Disciple clone... doable?

245

Comments

  • zubzub
    edited February 2013
    Severino wrote: »
    Ok. Installed x128, but It has no debugging mode. However It runs a 128k (toast rack) and with the gdos-3b.rom and the usual system disk It works fine. When using the unidos.rom and trying to load any system disk, It says error on disk, I can't remember the error exactly, something like sector missing or something like that. I will try other emulators though.

    Thanks! Interesting that it works under X128...

    I've just tried DISCiPLE emulation under RealSpectrum 0.97.26, and found that it doesn't work properly with the British 128K toastrack selected. I get similar screen content to that which I get if I try to use the DISCiPLE under Fuse's 128K emulation:

    RealSpectrum-128K.png
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I downloaded Z80 emulator, both for DOS and for win, the page on WoS says that is not shareware, but when installed It keeps saying that I can't use the disciple.
    I have installed spectraculator in trial, It has a debugging mode. I will try it on wine using playonlinux, It shouldn't be difficult.
    I did have problems because the debugging didn't allowed me to make a file with the code, I'll keep on it.

    On other order of things, I've been looking for some DIY'ers that made a +D copy, I was very interested on a design that was modular, one pcb for the speccy connector, another pcb for the ram/roms/pal, and the latest pcb was for the diskette controller. If this could be done using 3 smaller pcb's It could be better yet.

    I have 2 ideas on my mind at this point:

    a) Make the lite version and start debugging and see if it works at all.

    b) Separate the design on three PCB's.
    - 1 PCB with the connector to the speccy; through a pcb, use a
    IDC60 connector to plug into the main pcb.
    - Main PCB with through connector and the IDC male from the first
    pcb. This PCB will have IDC 34 connector, the purpose is
    to allow the other pcb to acces the signals discussed on the
    previous reply. The "lite pcb" will use these signals and
    makes the job. This pcb doesn't need to have all the
    connectors nearby, the joysticks sockets can be put on their
    original position, the inhibit and the nmi button, etc, the
    printer output can be done with a db25 parallel port type. Of
    course I don't plan on using the 9V from the speccy, tha same
    psu used for the disk drives (2) will give 5v regulated for the
    disciple.
    Anyway I can start by making the "angle adaptor" because I will need it anyway for the lite version.
    I will take a good look on the disciple enclosure and I will ty to make one out of wood (I was a luthier after all), metal is OK too, but I'm not very skilled on metal or aluminum.

    Just came to my mind that this breaks all the concepts of keeping the disciple away from the speccy, after testing the lite version (on a 48k+) we will see which is the better aproach.

    About the emulation, I've read that there was several rom versions, v1, v2 and v3 of the roms, theres a thread here In wos and came to say that v3 of the roms were compatible with 128k snapshots, previous ones were not. It can help you with the emulation. I'll keep on spectraculator.

    I read that UniDos only addition was allow subdirectories on the disks but I don't think that a FDD with 720K will have so many directories.
    In order to make the system disk for the rom, you need to load the tape here in WoS for V2, I don't know If V2 supported 128k snapshots.

    Ok, enougn for tonight.

    Regards.
  • zubzub
    edited February 2013
    Severino wrote: »
    About the emulation, I've read that there was several rom versions, v1, v2 and v3 of the roms, theres a thread here In wos and came to say that v3 of the roms were compatible with 128k snapshots, previous ones were not. It can help you with the emulation. I'll keep on spectraculator.

    I've only ever seen the DISCiPLE v3.0 ROM. People keep labelling it 'GDOS' but I think they've got that wrong... the DOS is what's loaded from disk (or tape, initially) into RAM. Actually, the DISCiPLE ROM images that I've seen are 16384 bytes in length, but the upper (or sometimes lower) half of this seems to be a dump of the DISCiPLE's RAM after loading of GDOS... so I'm wondering if the real problem here is that half of the ROM image is missing! Might it be that the missing half of the DISCiPLE ROM (if it is missing) determines whether the machine is a 128K Spectrum on bootup, and if not, switches to the other half of the ROM...?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    The discipel has 8K of rom and 8K of ram, so (I guess) the 16K dump is both rom and ram, only 8K of rom and only 8k of ram, so one half of the archive has to be the rom, check the complete disciple dissasembly, I will print it for proper study of the disciple later.

    Right now I'm getting the pcb to "very lite", only the diskette controller, but still is very big. I may get a same sice pcb for debugging and once It's working maybe we can use a microcontroller to replace rom and ram and maybe the pals, It will make the design much smaller.
    Just throwing ideas, but when I know fo sure that the clone is working.

    I can get spetraculator or whatever their name is to make a dump of the rom in the disciple? Or any emulator?. Make a small code that read the rom and then save it to ram, to a mgt disk or anything, this will simplify your work (and mine).

    Kind regards.
  • zubzub
    edited February 2013
    Severino wrote: »
    The discipel has 8K of rom and 8K of ram

    No, sorry, it doesn't. That's a 16K?8 EEPROM and A13 is wired up appropriately to allow selecting between two banks of 8K.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    Yes you're right. The first page of the rom are called "system routines", the second part "rom routines", I got the disciple-epson.rom, opened it with an hex editor and the expected texts are there as described by "the complete disciple dissasembly" however, the pagination system seems rather strange to me (without looking hard) It comes from a register at gets it from D3, I guess It should come from the pal's directly to a register, but I'm still in my way to print the dissasembly.
    Regards.
  • zubzub
    edited February 2013
    Severino wrote: »
    Yes you're right. The first page of the rom are called "system routines", the second part "rom routines", I got the disciple-epson.rom, opened it with an hex editor and the expected texts are there as described by "the complete disciple dissasembly" however, the pagination system seems rather strange to me (without looking hard) It comes from a register at gets it from D3, I guess It should come from the pal's directly to a register, but I'm still in my way to print the dissasembly.
    Regards.

    I think the 'system routines' that you're looking at are actually a dump of the DISCiPLE's RAM with GDOS loaded. They should not be programmed into ROM. The various 'ROM dumps' that are around were probably created by saving the first 16K of memory using the DISCiPLE. Since the DISCiPLE ROM and RAM are paged in when saving files to disk, this results in the ROM and RAM being saved to disk, rather than Sinclair BASIC.

    This leaves 8K of the ROM potentially missing, and not yet disassembled.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    The Disciples ROM and RAM banks have no fixed upper/lower position, as I recall.
  • zubzub
    edited February 2013
    roko wrote: »
    The Disciples ROM and RAM banks have no fixed upper/lower position, as I recall.

    Yep. According to the documentation that we have, A13 of the 27128 is controlled by bit 3 of the control port (#1F). The DISCiPLE ROM *and* RAM are both paged in upon execution at certain addresses (although it's not clear whether these are '#0001, #0008, #0066 and #028E', '#0000, #0008, #0066 and #028E', or some other set) and upon writing to port #BB ('patch'). The Spectrum ROM is paged back in by reading from port #BB. Reading from port #7B ('boot') places the DISCiPLE ROM at #0000 and the RAM at #2000 whenever the DISCiPLE is paged in. Writing to the port places RAM at #0000 and the ROM at #2000, instead. The initial state is for ROM to be placed at #0000.

    Unfortunately though, if we implement this, the 128K doesn't execute a sane set of instructions on startup...

    Our understanding of the behaviour of ports #7B and #BB is pretty clearly correct (or very close to correct) from reading of the disassembly. I really wonder whether the problem is that half of the ROM is missing... and the half that is missing detects whether the machine is a 128K, and does something different if that is the case.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    Hi.
    I've been reading about that. At any documentation (and short of having a chip dump made properly pulling it out from the disciple).
    It insists in 8K of rom.
    What If, the pagination, and forgive me If It looks sily, I still haven't take my coffee, moves ram and rom, but the second page in the rom is the same, the two pages are identical but you can "move" the rom from #0000 to "#2000". A shift that put the rom in that position; any direction starting with #2000 has the A13 bit in "1", which enables the second page of the rom, but It is still the same rom copied twice. Until #3FFF, the ROM is still with A13 at "1", which gives the second page of the rom.

    What do you think?
  • zubzub
    edited February 2013
    Severino wrote: »
    Hi.
    I've been reading about that. At any documentation (and short of having a chip dump made properly pulling it out from the disciple).
    It insists in 8K of rom.
    What If, the pagination, and forgive me If It looks sily, I still haven't take my coffee, moves ram and rom, but the second page in the rom is the same, the two pages are identical but you can "move" the rom from #0000 to "#2000". A shift that put the rom in that position; any direction starting with #2000 has the A13 bit in "1", which enables the second page of the rom, but It is still the same rom copied twice. Until #3FFF, the ROM is still with A13 at "1", which gives the second page of the rom.

    What do you think?

    Unfortunately, that's not the case. The A13 input to the ROM does not come directly from the Spectrum bus, but is taken from bit 3 of the control port (#1F) as I said previously.

    That means that when the ROM and RAM are swapped, A13 to the ROM remains the same. You have to actually perform an OUT instruction affecting port #1F to get at the other half of the ROM.

    You are right that there is no reference to the other half in the disassembly, though. It is plausible that both halves are the same, but I would imagine it would be cheaper to use a 8 KiB ROM instead... unless a change was made to the board to allow use of a 16 KiB ROM instead, but the software for this was never written, because M.G.T. decided to make the +D, instead?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    Unfortunately, that's not the case. The A13 input to the ROM does not come directly from the Spectrum bus, but is taken from bit 3 of the control port (#1F) as I said previously.

    That means that when the ROM and RAM are swapped, A13 to the ROM remains the same. You have to actually perform an OUT instruction affecting port #1F to get at the other half of the ROM.

    You are right that there is no reference to the other half in the disassembly, though. It is plausible that both halves are the same, but I would imagine it would be cheaper to use a 8K?8 EEPROM instead... unless a change was made to the board to allow use of a 16 KiB ROM instead, but the software for this was never written, because M.G.T. decided to make the +D, instead?

    In the +D they used a bigger rom and hard wired to "0" A13 and A14.

    The web where I read that said that could be that MGT had stock of those roms and had to use them.

    Maybe mgt had in mind more code for the rom, maybe the only thing that lacks the disciple, a RS-232 and... well I don't know.

    Have you tried the simulation with 2 copies of the same rom?

    48k emulation? 128k?

    Regards.
  • zubzub
    edited February 2013
    Severino wrote: »
    In the +D they used a bigger rom and hard wired to "0" A13 and A14.

    The web where I read that said that could be that MGT had stock of those roms and had to use them.

    But if that's the case, why wire A13 up to the control port? Why not wire it to '0' as they did with the +D? What about compatibility with software for older DISCiPLEs that had 8K, if they existed? The 16K ROM really strikes me as being something that would have been there from day one, especially given that new PCBs would otherwise have been required to wire up A13.
    Maybe mgt had in mind more code for the rom, maybe the only thing that lacks the disciple, a RS-232 and... well I don't know.

    That seems plausible... but there's not much point in speculating. We really just need somebody who has a DISCiPLE to send us a full dump of the ROM. It should be quite easy to do this from software, without taking apart the DISCiPLE.
    Have you tried the simulation with 2 copies of the same rom?

    There's not much point. The other half of the ROM is not paged in during the initialisation sequence of the 128K prior to the CPU executing the 128K error routine. My assumption that the contents of the other half of the ROM might hold a clue is based on the theory that this other half of the ROM might be paged in by a reset.
    48k emulation? 128k?

    I'm not quite sure what you mean. Fuse's DISCiPLE emulation seems to work for the most part with the 48K selected. The fact that RealSpectrum fails in a similar way with 128K emulation enabled suggests that this isn't a bug that's specific to Fuse (although that doesn't necessarily rule one out), but is more likely to be a problem with the schematics/equations/ROM images.

    I think that this point, we just need help from somebody with a real DISCiPLE. Any takers? :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I currently have my disciple opened up (I was replacing the 7805). If you would like to give me details of what you are after (and specific instructions) I can check it out sometime tomorrow.
  • zubzub
    edited February 2013
    fatbob wrote: »
    I currently have my disciple opened up (I was replacing the 7805). If you would like to give me details of what you are after (and specific instructions) I can check it out sometime tomorrow.

    I'm not sure, but I would imagine that high resolution photographs of both sides of the PCB would be very helpful to Severino in confirming the schematics. If you do this, then I imagine it would be important to avoid damage to the EPROM from any camera flash, though! So I guess make sure the EPROM's window is safely covered first?

    I would like a dump of the ROM, but we can probably achieve that from software, without needing the DISCiPLE to be opened up. If you are able to dump the ROM without my help and without any risk, don't let me stop you, though! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    OK I will see what I can do tomorrow - I can easily dump the ROM. It is an Issue 3 rom IIRC.

    I dont think my camera will give better results than the pictures that are already on here but I will give it a shot.

    Have you read the articles in Format Magazine (Issue 3.01 onwards) for hints about the operation of the Disciple?
  • edited February 2013
    zub wrote: »
    ...it would be important to avoid damage to the EPROM from any camera flash, though! So I guess make sure the EPROM's window is safely covered first?
    A piece of black insulation tape is good at protecting EPROM's from light :-)

    Mark
  • zubzub
    edited February 2013
    fatbob wrote: »
    OK I will see what I can do tomorrow - I can easily dump the ROM. It is an Issue 3 rom IIRC.

    I dont think my camera will give better results than the pictures that are already on here but I will give it a shot.

    Have you read the articles in Format Magazine (Issue 3.01 onwards) for hints about the operation of the Disciple?

    Thanks!

    BTW, I can't seem to find any existing pictures. At least, there's nothing at ftp://ftp.worldofspectrum.org/pub/sinclair/hardware-pics/...

    I see in Format volume 3, issue 4, page 11:
    As stated earlier the PROM used is UV erasable. The device used is a 2764 CMOS EPROM of 65536 bit cells organised as 8192 ? 8 bit arrays. The big advantage of our ROM is of course that the data will still be there when next we power up the Speccy.

    This would seem to contradict the schematic on WoS, although perhaps there are at least two different revisions of the board?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    This would seem to contradict the schematic on WoS, although perhaps there are at least two different revisions of the board?

    Yes It does, I must be blind, real blind. This is a picture of the disciple from the pictures I've been talking about, and It's a 28C64, and A13 of course doesn't have connection (NC).

    8498667835_de1c62d823.jpg


    This is the thread here on WoS, The pictures are OK, but nothing can be seen under the angled connector.

    http://www.worldofspectrum.org/forums/showthread.php?p=632337

    And thanks for the Format articles!! They will prove to be very useful.


    About the 8k /16k rom, here is a copy/paste from that same post, answered by Rudy, the author of the dissasembly:
    Translated:
    "The DISCiPLE originally has an 8K ROM (and also 8K RAM).
    A 16K rom is supported, you can switch between the two 8K banks by port 31, but the DISCiPLE system always resets that bit.
    So you can use 8K or 16K"


    I have the DISCiPLE rom disassembly in book form (also from Rudy).
    I asked Rudy why a 8K rom works, as there seem to be important routines in the rom (according to the book) from 0x2000, the higher 8K.

    But I just checked again: those routines from 0x2000 are merely a copy of the lower 8K.
    So indeed: there is an option to switch between banks, maybe for experimental use.

    So, I learned something new.
    .
  • zubzub
    edited February 2013
    Severino wrote: »
    I have the DISCiPLE rom disassembly in book form (also from Rudy).
    I asked Rudy why a 8K rom works, as there seem to be important routines in the rom (according to the book) from 0x2000, the higher 8K.

    But I just checked again: those routines from 0x2000 are merely a copy of the lower 8K.
    So indeed: there is an option to switch between banks, maybe for experimental use.

    So, I learned something new.

    I'm afraid you're mistaken ? the high 8 KiB is not a copy (if the schematics are to be believed), as I keep saying! :-) It is actually the same 8 KiB of ROM mapped to a different address range. A13 of the ROM is not connected to A13 of the Spectrum expansion bus.

    It may well be that any 16 KiB ROMs that M.G.T. burnt had both halves programmed with the same data, but I've not had any report of this being confirmed by means of a dump of the ROM. I also haven't had any assurance that the DISCiPLEs with only 8 KiB of ROM actually work in 128K machines, although this seems more likely to me now than it did before.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I have just done a dump of the 27C64 that is in my disciple and can confirm that it ie exactly the same as the disciple rom that is distributed with the eightyone emulator.

    I am trying to get some decent photos underneath the edge connector and under the socketed chips.

    Oh I forgot to mention - this unit works with my 128k toastrack.
  • edited February 2013
    zub wrote: »
    I'm afraid you're mistaken ? the high 8 KiB is not a copy (if the schematics are to be believed), as I keep saying! :-) It is actually the same 8 KiB of ROM mapped to a different address range. A13 of the ROM is not connected to A13 of the Spectrum expansion bus.

    It may well be that any 16 KiB ROMs that M.G.T. burnt had both halves programmed with the same data, but I've not had any report of this being confirmed by means of a dump of the ROM. I also haven't had any assurance that the DISCiPLEs with only 8 KiB of ROM actually work in 128K machines, although this seems more likely to me now than it did before.

    Zub, I didn't say that A13 on the rom bus is from the speccy bus, It comes from IC5, a register updated by clock signal.

    In this picture:

    8498667835_de1c62d823.jpg

    The rom is a 28C64, a 8kx8 eeprom, in the schematics and for what I can tell from the pcb tracks, A13 to the rom is indeed connected to pin 15 of IC5, a register updated by CLK signal generated by pin15 on pal IC9.
    But any change on that pin would be ignored by this chip.

    A different Issue of the disciple would have different rom and different pal's for use that part of the rom. All this work is based on the assumption that Ok, there were different roms, but always with the same pals.

    If the pals were changed... I don't know where we can get that information. We will need the rom compatible with the 128K and "decode" the pals on that specific disciple unit.

    Regards.
  • edited February 2013
    fatbob wrote: »
    I have just done a dumpof the 27C64 that is in my displae and can confirm that it ie exactly the same ad the disiple rom that is distributed with the eighyone emulator.

    I am trying to get some decent photos underneath the edge connector and under the socketed chips.

    Oh I forgot to mention - this unit works with my 128k toastrack.

    That would be fantastic. Thanks!

    For the bottom (tracks only) I've found that scanning instead of taking pictures works much better. If you can do that It will help a lot.
  • zubzub
    edited February 2013
    fatbob wrote: »
    I have just done a dump of the 27C64 that is in my disciple and can confirm that it is exactly the same as the disciple rom that is distributed with the eightyone emulator.

    I am trying to get some decent photos underneath the edge connector and under the socketed chips.

    Oh I forgot to mention - this unit works with my 128k toastrack.

    Thanks!

    I see that the 27C64 is an 8K?8 ROM, so what you really means is that it is the same as the first half of the ROM that is distributed with eightyone. This is also the same as the image distributed with X128, half of the image that in the RealSpectrum ROMs collection, and half of the image that we were going to distribute with Fuse.

    Since we still don't know what the upper half of any 16 KiB ROMs looked like (if any 16 KiB ROMs were ever even burnt at all!) I'll simply remove half of the image that's distributed with Fuse, at some point... and I'd go so far as to recommend that other emulator authors do the same, and will talk to Phil about getting his Spectrum ROMs collection updated.

    Note the comment about ownership of GDOS (the DOS, not the ROM!) in the X128 documentation.

    I am not sure how safe it would be to take a snapshot of the DISCiPLE RAM on one machine (such as a 48K) and then use it as the initial state for a different machine (such as a 128K). I imagine that there isn't anything that is machine-specific stored in the DISCiPLE RAM, but do not know this for a fact.

    After a reset, I expect the DISCiPLE would distrust anything in RAM relating to the contents of the disk. It would really have to, as if disks are changed whilst interrupts are disabled (e.g. whilst in a game) and then a reset is performed, the any information regarding the disk would definitely be invalid. In a way, it would have made more sense to me to have cleared any data in the snapshot of the DISCiPLE RAM that the DISCiPLE will clear upon a reset anyway, though...

    So...

    This leaves the question of what on Earth is going on. For now, I shall take a look at EightyOne and see if that answers any questions. :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I opened the rom from EighyOne. It's a 16K file, opening it with an hex editor confirms that beyond #1F4A the file is filled with "0"'s, put the #2000 shift and you will get the same from Rudy dissasembly; from #3F4A to #3FFF "unused", and so on until filling a 16K rom. It's empty, not "doubled".

    I guess this get us more questions than answers, but at least we got the right ROM to work with, I'll keep working on the schematic.
  • zubzub
    edited February 2013
    Severino wrote: »
    I opened the rom from EightyOne. It's a 16K file, opening it with an hex editor confirms that beyond #1F4A the file is filled with "0"'s

    I did the same... but since it was said that an 8 KiB ROM had the same content as a 16 KiB file, I was slightly worried — I was wondering whether some different version of EightyOne actually had an 8 KiB ROM image! IMO, the right way to deal with this is to talk about a checksum of some sort of the data — the MD5 sum of the 8 KiB image that you're referring to is 78e61a2a02121873c1756b21fd1398b1 — putting it this way leaves no ambiguity. :-)
    Put the #2000 shift and you will get the same from Rudy disassembly; from #3F4A to #3FFF "unused", and so on until filling a 16K rom. It's empty, not "doubled".

    Well, Rudy's disassembly, as far as I can see, only covers a range of 8 KiB (from #2000 to #3FFF, as you say, since it assumes GDOS is loaded)... but it says nothing about what's in the other 8 KiB of a 16 KiB ROM, if such a ROM ever even existed. Until you actually see a 16 KiB DISCiPLE ROM you have absolutely no way of knowing what's programmed in the other 8 KiB.

    That is, unless you can find some bit of code in the 8 KiB ROM or in GDOS that would page the other half in... but I think it's already been said that there's no such code in Rudy's disassembly.
    I guess this get us more questions than answers, but at least we got the right ROM to work with, I'll keep working on the schematic.

    It does... but we're getting closer. As you say, we know we have the right ROM! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Severino wrote: »
    Zub, I didn't say that A13 on the rom bus is from the speccy bus, It comes from IC5, a register updated by clock signal.

    In this picture:

    8498667835_de1c62d823.jpg

    The rom is a 28C64, a 8kx8 eeprom, in the schematics and for what I can tell from the pcb tracks, A13 to the rom is indeed connected to pin 15 of IC5, a register updated by CLK signal generated by pin15 on pal IC9.
    But any change on that pin would be ignored by this chip.

    Ah, okay, then ? it was the use of the word 'copy' that had me worried! :-)
    A different Issue of the disciple would have different rom and different pal's for use that part of the rom. All this work is based on the assumption that Ok, there were different roms, but always with the same pals.

    If the pals were changed... I don't know where we can get that information. We will need the rom compatible with the 128K and "decode" the pals on that specific disciple unit.

    It seems we have hardly any information at all on older issues of the DISCiPLE... I'm not sure they'd be worth emulating, but it might be nice to have ROM dumps from them, at the least...
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    OK here is a scan of the rear of the Disciple:
    8500169679_9868429894.jpg

    A couple of Photos attempting to see under the connector
    8501332124_2dcfaa1a43.jpg 8501333656_2e40f8740a.jpg

    and with the socketed chips removed:
    8501651986_886c48fb75.jpg

    Hope these are of some use - if you need anything specific looking at, just ask.
  • zubzub
    edited February 2013
    Severino wrote: »
    Have you tried the simulation with 2 copies of the same rom?

    For what it's worth, I have now made changes to Fuse to use only an 8 KiB ROM image, which is effectively the same as have two copies of the 8 KiB ROM's contents in a 16 KiB image... and this makes no difference. I still get a red border with black screen contents on bootup, shortly followed by a similar pattern to the screenshot of RealSpectrum that I posted previously.

    Some good news, though (perhaps)! :-D

    I have just made some experimental changes to Fuse, and found that if I alter the code so that the DISCiPLE ROM/RAM is not paged in upon a reset, and the memory is not paged in upon execution at #0000 or #0001, then the interface appears to work under 128K mode. At least, GDOS loads successfully, and 'CAT *' produces a directory listing without any problems. 8-)

    Assuming this is where the problem lies, I still wouldn't simply make alterations to the PAL equations on the basis of what I have said, though. There was apparently a proper dump of the GAL(?) contents made of a DISCiPLE that had been sent off for repair, which was not obtained by reverse engineering. I would suggest seeing if this dump is available. If not, the work of reverse engineering the PAL needs to be re-done with the PAL from a DISCiPLE that is known to work with 128K machines.

    I would still recommend checking the schematics against photographs from fatbob's DISCiPLE, too, since it's known to work with a 128K machine, and I'm not sure of the origin of the other photographs. (TBH, I've tried and utterly failed to find them anywhere!)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    bverstee's original hi-res pictures are here
Sign In or Register to comment.