Indeed, standard XGA is only 65 MHz. In fact, standard 1280x1024 (60 Hz) only requires a 108 MHz clock. Assuming lower depth (probably no more than 16 colors/4 bits) to fit in the available VRAM, it might be within reach. Even it the HW can't reliably do 108 MHz, it might be possible to lower the refresh rate a bit and shorten some of the long porches when talking to a LCD. Native 1280x1024 17" LCDs with a VGA input are still plentiful.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
vpRowBytes in video card declaration ROM
- Thread starter ymk
- Start date
Phipli
Well-known member
Ah, but I was curious from the phrasing if it was possible purely in software without burning a ROM, and I was talking about the Toby originally.
But its getting off topic. I'll keep it in mind for another time.
Toby cards (Mac II Video, High Resolution, and Workstation Video) would need an oscillator swap and an INIT that kicks out the ROM driver and installs its own. Do those handle anything high-res? I've only ever seen 640x480 for the Toby cards, and they pre-date all of the big monitors.
Phipli
Well-known member
I've said about needing this twice already!
There are spare, unused clock sockets on some variants of the Toby, specifically the TPD/Portrait I think AKA "Workstation".Some Tobys do 1152*870 at 4bit with 512k VRAM, the Workstation version, which worked with the TPD.
The Portrait version did 640*870 at... a bit depth. Guess 8bit. It has the VRAM if upgraded to 512k. Mine is greyscale (blue channel!) only. Not sure if that was universal.
Last edited:
cheesestraws
Well-known member
The framebuffer is simply memory mapped, but I have a feeling we discussed this before - wasn't it one of the palette indexing registers? Should be quite trivial to implement, especially now the MacOS q800 changes are upstream
Oh, that was what I was thinking of. Thankyou
Please disregard my earlier comment.Congrats on getting that upstreamed! Is there some limitation to QEMU's internals that the framebuffer isn't just readable? And does QEMU handle the Turbo SCSI halting the processor on pseudo-DMA, or does the 53C9X cheat and just always accept data? That took me over a month to work out for MAME because we enforce real SCSI bus delays
DAFB isn't bad if you only target one generation and use Apple's built-in declaration ROM. It does get more interesting when you have to handle all 3 Quadra generations that used it (and eventually HPV).
Thanks! No, there's no restriction there, it's simply mapped memory. I had no idea that the PDMA caused the CPU to halt, but not implementing it hasn't caused any problems that I am aware of. Given that QEMU runs at native speed I was expecting there to be some timing issues, but the only one I really found was CALCULATEDSLOD in the Toolbox ROM which overflows when calibrating the timer. The solution for that (and in a similar way, A/UX) was to spot specific access patterns to the VIA timers to work out when calibration was about to start and finish, and then overwriting a couple of low memory globals with some known good values at the end
Any disk I/O runs in a separate thread within QEMU, so I've made use of deferred interrupts e.g. when you submit a command to the ESP you don't get the bus service/function complete interrupt until the async I/O callback returns to indicate data is available. So far that seems to work well, although someone did point out the stress-ng on Linux can cause errors by pushing too much data in the FIFO: I haven't tried that recently though. Apparently on real hardware if PDMA can't get the data quick enough it generates a Bus Error on the CPU which is what Linux implements.
Have you managed to run any other OSs on MAME? I would expect that since it also emulates the hardware it should be possible to run other OSs such as Linux, NetBSD and A/UX without any issues.
Ahh. We do the actual "the 68K slows down to 700-odd kHz on VIA reads and writes", because the ROM .Sony driver relies on it heavily given Apple was doing cycle-counting floppy control for about 10 years longer than they should have.Given that QEMU runs at native speed I was expecting there to be some timing issues, but the only one I really found was CALCULATEDSLOD in the Toolbox ROM which overflows when calibrating the timer. The solution for that (and in a similar way, A/UX) was to spot specific access patterns to the VIA timers to work out when calibration was about to start and finish, and then overwriting a couple of low memory globals with some known good values at the end
DAFB can be set to either halt the CPU or trigger a bus error if a PDMA access happens and DRQ isn't asserted (so there isn't room in the FIFO), and there's also an option of how many cycles of wait state on accesses to the 53C96. The ROMs and MacOS set it to halt the 68k and the wait states according to the CPU clock.
It actually will work most of the time without either mechanism. But I found that if MacOS writes a sector from a non-word-aligned memory location the way it lines up the FIFO writes causes data loss without halting the '040. Once I had that working I could boot from Legacy Recovery with an unformatted HDD, format, and install any supported OS up to 8.1 with no errors.
A/UX starts to come up and then the video goes corrupt and the CPU jumps to infinity. I haven't tried to debug it yet, I wanted to get all of the non-AV Quadras booting first. After that happened I didn't want to debug Mac chipset devices for a minute (the ATA interface in the Q630/LC580 was annoying to figure out). For NetBSD the Penguin boot loader doesn't like me and I can't find the source to understand what it's mad about. I assume that would also be an issue for Linux. MAME does run a bunch of Unix versions for other m68k machines (SunOS, IRIX, HP-UX, Sony NeWS OS, Apollo Domain/OS, and NEXTSTEP) so I'm pretty confident it's not going to be a huge problem.
Oh wow, that's incredible. I knew that the floppy drive was timing sensitive, but not quite to that extent (SWIM just current debugs accesses in QEMU for now). The main use case is for the A/UX boot floppy, but that seems to work fine added as a SCSI HD to get to the installer. Maybe one for the TODO list if I ever feel like a challenge...
I see, thanks for the info. Certainly QEMU currently has no knowledge of this, but it seems to work so far. Ah yes the unaligned read/writes mixing FIFO and DMA commands... I remember that well as it required quite a large rewrite of the existing ESP device (and indeed, I still have another in the pipeline)
. Presumably the issue you had here was because of the DRQ line timing halting the CPU when it's trying to setup the transfer?Yeah video corruption normally means a panic: A/UX switches to 1-bit mode, but it can generally manage to output some messages to give an idea as to what happened. From memory A/UX support was reasonably trivial and only required a few changes:
- Shadowing the Toolbox from 0x48000000 into 0x40000000 (for some reason A/UX accesses via the lower address range?). At least in the Q800 developers guide it is listed as part of the Toolbox ROM area, and it works...
- Implementing the extra EASC registers. I'd initially implemented just the ASC registers but A/UX panics with a fault if the extended register sets aren't present
- Implementing the"auxmode" interrupt routing switch (also used by Linux, NetBSD). This took me a little while to work out because MacOS works fine in both routing configurations - I guess they played safe given that it is a so-called "Universal" ROM
Interestingly enough I've also had a report that MachTen works on MacOS 7.5 under QEMU so there is still plenty more fun to be had...
(BTW: apologies all if we've hijacked this thread: let me know if this isn't interesting and we can move the discussion elsewhere)
That makes sense. Is read access to the CLUT essential?
I don't think there's a selector to read back from the CLUT - just to set it. So reading back from the CLUT isn't needed.
Only the framebuffer memory is used directly by quickdraw, in whatever format the driver has specified (8-bits indirect, 146bits direct, ...). Everything else is purely inside the driver, used only through the selectors in Contorl() and Status(). So if the Mac needed some information back that the driver couldn't retrieve from the hardware, typically it would be 'shadowed' by the driver in its private structure when it was written (or the default would be assumed if never written).
cheesestraws
Well-known member
There is: https://github.com/cheesestraws/aux-minivnc/blob/main/kernel/src/fb.c#L154
But I don't think it's strictly necessary to do anything sensible with it.
Mmm, you are right. It's not in Control, but in Status. And from my comments and the implementation (just an illegal instruction...), it's never called in any of the Systems I've tried.
... which also means the current DeclRom for the NuBusFPGA might not be compatible with A/UX, if A/UX does call that selector. But I don't have A/UX to test it.
