Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    As you say, I only need a very small part of the SCC, but the Mister SCC code was not easy to understand.
    Paul Ruiz
    @pnru_gitlab

    OK, that is good to know: the Blit terminal also uses 90 deg phased signals to read its mouse - I can reuse that conversion.

    For the mouse part of the SCC, I would just implement a single register with the two bits and an interrupt circuit. Sounds like a dozen lines of code.

    Lawrie Griffiths
    @lawrie
    Yes that sounds right.
    Paul Ruiz
    @pnru_gitlab
    Not sure how the interrupt gets reset - maybe reading the register does that as a side effect.
    Lawrie Griffiths
    @lawrie
    Presumably when I get a packet from the ps/2 mouse, I just work out the direction and if x or y has changed, set the 4 bits (x1, x2, y1, y2) and trigger the SCC interrupt.
    Paul Ruiz
    @pnru_gitlab
    Yes, that sounds right :^)
    For the disk, what is the format of the images? If those contain 6-2 encoded bytes, sticking with that format will be the easiest. I think the ROM will basically manipulate the DIR and STEP signals to move to a track and then read or write the track in a tight loop. I suppose the stuff to control motor speed, write underflow, etc. can all be ignored. The verilog would read/write a buffer, and signal the ESP32 to fill/read the buffer (much like the QL design).
    Lawrie Griffiths
    @lawrie
    The other issue is how to support two floppy disks from the ESP32 side.
    I will start with one, but a practical system needs both the internal and external floppy.
    I am not planning on doing the scsi hard disk controller.
    Lawrie Griffiths
    @lawrie
    I think the Mister code downloads the whole floppy image into SDRAM.
    emard
    @emard
    I can support 2 disk drives from esp32, python can open multiple files (disk images), OSD GUI can be modified for this. Of course filling SDRAM solution would be much faster, if it can be copied from Mister and got working ok
    emard
    @emard
    Simplest hack I can think of is to use different button (F1 instead of RIGHT btn) to load image to "second" drive. If disk controller cannot stream from both drives simulataneously, then just one bit added to track request could select to take data from first/second drive.
    Paul Ruiz
    @pnru_gitlab
    The Mister code derives from an earlier, simpler project "Plus Too" on big mess o' wires. It may have just what you are looking for. See this page:
    http://www.bigmessowires.com/2012/12/15/plus-too-files/
    It has a tool to convert a regular disk image to an image with 6-2 tracks and puts that in flash I think. There is floppy code to read bytes from flash to the CPU (see the file floppy.v in the source code archive on that page). It seems this project was doing exactly what you are aiming for: a quick fix to get something running. It also has a preprocessed system disk image in the archive).
    emard
    @emard
    I have board with serdes banks powered, I'd like to start with anything that compiles, and experiment with some input. I found this on the net https://github.com/emard/ulx3s-misc/blob/master/examples/serdes/top/top_serdes.v#L29 but it doesn't compile.
    jamon
    @jamon
    Do the chips used on the production ulx3s' support serdes? or are you experimenting with a different chip?
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab Yes, I knew of the existence of that project but had not looked at its code. I will see if it is simpler than the code that is now in the Mister project. The Mister project contains the pre-processed System 6 disk.
    @emard I believe the Mac only uses one disk at a time.
    emard
    @emard
    @jamon I'm experimenting with prototype v3.1.4 PCB. The boards sold at mouser v3.0.8 do not support serdes and of course chips soldered are non-serdes models.
    Paul Ruiz
    @pnru_gitlab

    @lawrie Had a second look. Complexity looks manageable, but I'm not sure it translates 1:1 to the ULX3S.

    The essence of the floppy stuff is in two files: iwm.v (this implements the logic of the drive controller 275 lines) and floppy.v (this implements a model of the floppy drive, 375 lines). If I understand the code correctly, it skips (de-)serialising the data and passes bytes between the two instead - which makes sense. The floppy model implements a fake motor speed signal, which I guess is needed for the Mac ROM code to work.

    The floppy model gets its data from a parallel flash chip on the Altera DE1 board - for which we do not have a direct equivalent on our board. I think the iwm.v code can be used more or less in tact (probably it is also in the Mister code). The floppy.v code would need the flash rom replaced by an interface to the ESP32. Doable, but not a 10-line fix.

    David Shah
    @daveshah1
    @emard remove the bel attribute and replace it with (* LOC = "DCU0" *) - or DCU1 if using channel 1
    Paul Ruiz
    @pnru_gitlab
    @lawrie One way to modify the floppy code could be to replace the flash memory with a block ram large enough to hold 12 sectors + formatting (a little over 2KB, I think). Whenever the track number changes, the ESP32 is asked to refill the buffer with the new track. The code already has a bit to signal that the track change is ready, as that exists on the real H/W too. The R/W code can then refer to the buffer instead of flash rom.
    emard
    @emard
    @daveshah1 Thanx, now I'm getting different errors, this is good hint
    emard
    @emard
    nextpnr-ecp5 --timing-allow-fail --12k --package CABGA381 --json serdes.json --lpf ../../constraints/ulx3s_v31.lpf --textcfg ulx3s_12f_serdes.config
    ....
    ERROR: no DCU location 'DCU0' in device 'LFE5U-12F'
    ERROR: Packing design failed.
    David Shah
    @daveshah1
    You need to use LFE5UM5G-12F
    • LFE5UM5G-25F
    and then change the idcode back in ecppack
    emard
    @emard
    Yes yes how to specify option with parameters exacty?
    David Shah
    @daveshah1
    --um-25k
    emard
    @emard
    ahaaa
    David Shah
    @daveshah1
    and then --idcode 0x21111043 to ecppack if the device is a LFE5U-12F
    emard
    @emard
    Super, --um-25k passed, and with idcode it will be easy now
    yes it is 12F :)
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I am currently working on the SCC code for the mouse, which is turning out to be a lot more than a dozen lines. The Mister/PlusToo code describes the SCC register access as semi-insane.
    Paul Ruiz
    @pnru_gitlab

    @lawrie I suppose the chip is pin constrained and hence has indirect addressing of its registers. The TI 9918 video controller from MSX has something similar. Inconvenient? yes; insane? maybe.

    It would seem to me that we are in luck that the DSD bit is located in register 0, which is the one that is selected by default. So, I would think that all that is needed in a minimal implementation is to respond to reads with ab[2] = D/C = 0 (i.e. control, not data) and ab[1] = A/B to select between X1 (A channel, 1) and Y1 (B channel, 0). The DSD bit (which is wired to X1/Y1) is bit no. 3.

    Lawrie Griffiths
    @lawrie
    This what I currently have by copying what seems to be the relevant code from the Mister project - https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L234-L258 and https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L436-L483
    Paul Ruiz
    @pnru_gitlab
    That is indeed more solid code, also implementing the reset functionality - which is probably a good idea. They seem to implement just a few of the write registers (0, 1, 9 and 15). Unless it is yours, the diagnostic lines can be removed I suppose. Maybe I am missing things, but it seems that there is no code for register reads yet?
    Lawrie Griffiths
    @lawrie
    Yes, the diagnostics is mine. I am just seeing what paths it is following.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I have added some SCC read code now. I don't think I am triggering the interrupt yet. I need to check all the logic.
    Paul Ruiz
    @pnru_gitlab
    @lawrie This doc may be useful: http://www.zilog.com/docs/serial/ps0117.pdf
    For the real part to generate an interrupt, the "master interrupt enable" (bit 3 in R9), the "external interrupt enable" (bit 0 in R1) and the "DCD interrupt enable" (bit 3 in R15) need to be on. You may see logic like this in the Mister code. Note that R9 is shared between channel A and B.
    On the read side, apart from bit 3 in R0 you also need to have R3A implemented: it has the bits to indicate whether the interrupt came from channel A (bit 3) or channel B (bit 0).
    Still not sure how INT is cleared. It may be through the autovector bus cycle, it could also be a software clear: set bit 5 in R9 to enable software clearing, and read R2 to actually clear.
    Paul Ruiz
    @pnru_gitlab
    Had another look at your code: it seems the Mac is reseting a channel to clear the interrupt - so that is already covered. It also seems to only look at the DCD IE bit in R15, and take the other two IE bits for granted. If it works on the Mister, it must be enough.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I pushed a new version with some fixes. The SCC irq is definitely triggered now. Not sure if it is cleared correctly. The led that shows it set is staying rather bright, but that might just be because it is lower priority than the VIA irq. I was hoping that the cursor would move round the screen, but that is not happening. The"?" on the floppy disk is also not flashing, but I was assuming that was because IWM was not yet implemented.
    Lawrie Griffiths
    @lawrie
    I have added the iwm and floppy code unchanged from the PlusToo project. It currently builds and runs as far as before. So most of the code is there now, I just have to make it work.
    Paul Ruiz
    @pnru_gitlab
    I'll have a look. The SCC interrupt line staying active does not sound right: if the mouse does not move I would have expected it to be completely off.
    Lawrie Griffiths
    @lawrie
    I think the mouse should move, so I suspect something is wrong. The variable that holds the mouse position does not change. But I can see that it is executing the SCC interrupt routine, as I can press a button to cause a CPU halt and see the address in the level 2 interrupt routine on the lcd diagnostics. It spends a lot more time in the vblank VIA interrupt. I believe the SCC interrupt is supposed to update the variable and the vblank interrupt is supposed to redraw the mouse pointer.
    The level 2 interrupt routine is at address 1A84 in https://www.bigmessowires.com/rom-adapter/plus-rom-listing.asm
    Lawrie Griffiths
    @lawrie
    The code says it is reading RR2B.