Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Rob S
    @rob-ng15
    Yeah the 640x480 bitmap is in block ram, admittedly only used for the Risc-V logo and the lives remaining in this game.
    I'll write up some documentation as there is quite a bit to the display stuff, including a basic GPU that can draw points, lines, rectangles, circles and triangles, the background layer, scrollable tilemap layer, two sprite layers with 13 sprites each, a character map, and a small terminal style overlay. Plus basic audio, UART, LEDs and button input. There is documentation in the j1eforth project it was developed in, but there are some changes now, especially to the sprite layer to move the bullets faster!
    emard
    @emard
    Great! 85F with code generators like silice, saxonsoc, nmigen etc has the luxury to make things this way. Using lot of BRAM is "cleaner" and more readable as source than SDRAM driver, which would surely provide any resolution and 200 sprites, but for asterioids game, it is fine how it is done with BRAM.
    Rob S
    @rob-ng15
    Yeah, I'm a novice at this, sdram is on my list of to-dos, along with sdcard. Then I can load programs into sdram from the sdcard.
    Paul Ruiz
    @pnru_gitlab

    @lawrie If you have a working implementation on Mister to guide you, maybe it is not all that difficult to add mouse and disk.

    The wikipedia page for the original Mac's describes the mouse, including its wiring across chips:
    https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details#Mouse

    The disk hardware is essentially the same as the disk hardware on an Apple ][:
    https://en.wikipedia.org/wiki/Integrated_Woz_Machine
    http://www.brutaldeluxe.fr/documentation/iwm/apple2_IWM_Spec_Rev19_1982.pdf
    I think once the registers that the controller presents to the software are known, doing a verilog replacement can be similar to what you did for the QL.

    Paul Ruiz
    @pnru_gitlab

    On the Mac, the rom just contains start-up code and device drivers. On the QL, it contained the whole operating system. The biggest part of Mac Plus rom seems to be the file system implementation.

    I'm not sure that is correct. See below link for some details:
    https://macgui.com/news/article.php?t=493

    Lawrie Griffiths
    @lawrie
    Yes, that is the rom listing I am using.
    Lawrie Griffiths
    @lawrie
    The rom may have a bit more than I said, but all the control is from the System and Finder files on the system floppy disk.
    I might be able to move the mouse around the screen without the system disk, but there would be no menus and nothing to type into.
    That IWM spec is also the one I posted a link to above.
    It is all doable but the SCC is a bit complex, and the floppy control is even more complex.
    Thanks for all the links. There were one or two that I hadn't seen.
    Lawrie Griffiths
    @lawrie
    I think there are a couple of options for the floppy disk controller. I can stick with the format that Mister uses that is very close to what is on the disks and uses the 6 2 encoding, or I could go for a simpler mapping.
    I think there are also options for how to do the mouse.
    The Mister implementation sticks fairly close to the original hardware. I only really want something as simple as possible that will execute the rom.
    Paul Ruiz
    @pnru_gitlab
    For the mouse, only a minimal part of the SCC needs implementing. The way I understand, all it does for the mouse is to provide access to the X1 and Y1 signals and generating an interrupt on whenever either one changes state. The ROM will read the X1 and Y1 signals, and the X2, Y2 signals from the VIA (along with the mouse button state) and figure out if the mouse moved up, down, left or right. Does Mister include code to convert PS/2 mouse packets to X1/2 and Y1/2 signals?
    Lawrie Griffiths
    @lawrie
    Yes, I was just looking at that.
    The Mister PS/2 code produces a 25-bit packet which I assume contains the x and y values.
    They are then converted back to the x1, x2, y1 and y2 signals.
    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