Fuckery delayed because microSD cards are, largely, awful
Ha found a working one
Ready for the fuckery
Hardware is good (red screen is because Pistorm doesn't handle bus arbitration properly so the CD drive can't be probed)
I have successfully turned the screen white. Having proven the overall concept, my next step is to port Doom.
("But Matthew", I hear you ask, "Isn't Doom, But On The Amiga already available?", to which I say "Yes, and that is not what I am doing, at least not in the way you think I am, and also what are you doing in my house")
This is not quite going to be @foone levels of fuckery but it is going to be the closest I've done for a while
Ok the palette is fucked but otherwise this actually works holy fuck
Interestingly I do need to run Kickstart before this works, so there's some register state needed here that I'm not explicitly setting (I'm setting the palette registers, DMACON, BPL*PT, DIWSTRT/STOP, DDFSTRT/STOP, BPL*MOD, BPLCON*, COP1LC*, not touching anything else)
Symptoms seem to be that writing anything to chip RAM and then reading it back doesn't show the writes landing, do I need to do something to turn on decode there?
Ahhhhhh the ROM starts off overlayed over RAM ok
Hmm setting 0xbfe001 to 0x2 should disable overlay and turn on the power LED, but neither appears to be happening and reading it back gives 0xff so where are my CIAs
Solving this in the most stupid possible way (dumping every register access from the emulator code, including that in my setup code, bisecting until things work)
This is just full on bewildering now, executing exactly the same set of register writes just does… nothing to the CIAs? Even sticking an extra sleep in the way does nothing. Time to poke shit further.
Oh FFS apparently it's necessary to hit the reset pin for the hardware to work even if it's just come up from cold?
What even is hardware
Ahhhhhh Amiga bitplanes are not ordered in the order I expected?
This seems almost right, but something is going weird in the palette calculations for some frames? I'm redrawing the entire screen but it's only happening in the play area so it feels like the engine must be sending me bullshit hrmmm
Ah shit is this because I'm updating bitplanes without syncing to vblank? Fuck fuck fuck ok that would explain everything ok time to double buffer
@mjg59 It’s like playing doom on an old VHS 😍
@mjg59
Ah bitplanes, that takes me back. I don't miss them though.
@mjg59 Kinda depends on what you expected i guess...
The Amiga was mostly designed in Britain i believe, which would obviously make some design decisions awkward.
@mjg59 is a softcore instanced on an FPGA hardware
@mjg59 “hardware is the parts of the system we can kick, software is the parts we can only swear at”
@mjg59 source is an old fortune file I found once upon a time I’m pretty sure
@kevinriggle @mjg59 Misread as "Hardware is the parts of the system we can lick," made just as much sense anyway.
@mjg59 targets for yelling at because nothing is remotely documented correctly, and what you need is in the errata to the errata to the errata verion 3 no really final this time document?
@mjg59 beware of the thinking rocks, for they are cunning and sly
@mjg59 Cold power-on is the original hardware RNG

@mjg59 it’s pretty common for hardware to require a reset cycle from outside at power on in order to trigger initialisation of registers / state to a “known starting state”. Otherwise you get “whatever charge the flip flops happened to have at power on”, and or janky state from power rails coming up.

Most older microcomputers have a RC circuit or timer to assert reset for some ms until they’re sure power is stable and reset steps happened.

@ewenmcneill in this case the CPU apparently needs to execute reset as the first instruction

@mjg59 that’s somewhat unusual (historically it is a board wide reset signal to all chips).

I guess they chose that approach as it ensures the chipset gets reset after the CPU has started executing code.

@mjg59 I think the Gary chip is responsible for some of the chip selects and I wonder if that needs some initialisation? Never seen any documentation for it though
@bwh guess I'm reading Kickstart source
@bwh annoyingly all the writeups I can find of doing "bare metal" bringup are running in UAE which obviously does not have identical behaviour
@mjg59 I'm looking at coldstart.asm now. I don't see any sign of initialisation of Gary on the 68000-based systems before it accesses CIA registers , but I do see that it checksums the ROM which would take a few million cycles. Maybe you just need a longer delay after reset?
@bwh The Pi needs to boot before I touch hardware, so unless it's in response to some other access the hardware has been stable for some time. I'll take a look at the other accesses and see if I can get it behaving.
@mjg59 suddenly your earlier questions make a terrifying kind of sense
@mjg59 hmm can i guess what you're doing? are you running doom on the pi but doing some chunky2planar thing and writing the image back to the amiga's chip ram over the bus? :33
@mntmn yup, zero 68K code is being executed here
@mjg59 haha, very nice! i was wondering how feasible this was. how much bandwidth / FPS do you get?
@mntmn haven't benchmarked yet, and also unsure where the bottlenecks might be (but also I've got at least a 2x speedup on video bandwidth by not writing 8 bits at a time)
@mjg59 I read this in the voices for "Valve Source Code Comments"
the rapidly dwindling sanity of valve programmers as expressed through code comments

YouTube
@mjg59 The impressionists or maybe the dadaists would be happy with your results right now. ;-)
@mjg59 haha. such a cool project. Love the madness!