<geist>
mrvn: well, sure, but no one currently makes a 68030 board, since the pinout is substantially more complex
<zid>
20 more complex, I think
<geist>
yah 030 is iirc fairly similar to 020 signal wise, though i think it's a little more complicated to support external caches more
<geist>
i've been studying it a bit with the intention ot eventually making a board, but either you need a lot of external TTL logic to deal with the bus cycles or you need a CPLD/FPGA to do it
<geist>
since it has a fairly complicated synchronous external bus
<geist>
not insurmountable, a fpga would do fantastic, but it is defiitely somewhat of a state machine
<gog>
probably easier with a CPLD than a bank of 74xx TTLs
<geist>
68000 and 68010 are simple enough that it's kinda like a fast 6800 class machine, though even the rosco board uses some PLAs for address decoding, but they could have done it with a handful of TTL chips
<geist>
gog: yeah there's some stuff with the 030 bus that deals with things like unaligned accesses., it's a 32bit data bus but it is apparently free to ask for completely unaigned accessses at 8 16 or 32 bit wide
<geist>
and there's some complexity about providing different bytes on different 'lanes' of the D0-D31 bus
<geist>
i *think* you can cheese out and just provide 8 bit data if it's unaligned and the cpu will just keep fetching
<geist>
it also has a burst mode transaction which is synchronous, it starts a sync transfer and then expects ou to deliver subsequent addresses on subsequent cycles. used to fill the internal cache
<geist>
so that alone seems to mean yo uneed at least some sort of external address latch with at least a rudimentary adder
<geist>
i *think* you can NAK that and it'll just treat the range as uncached
<gog>
idk enough about the 68k's pipeline to really know what feeding it unaligned data would do
<gog>
at least without the supporting logic
gildasio1 has quit [Quit: WeeChat 3.5]
<geist>
the 030 manual talks about there being a block in the cpu that deals with bus transactions and swizzling things around. i think it would just end up stalling, waiting for data to show up
<geist>
also means you can legitimately wire up say a 16 bit bus to an 030 and just NAK the high bytes on every transaction
<geist>
and it'll just spend extra cycles doing what it needs to do
<geist>
which some of the later, cheaper macs did, even. Mac Classic I think was an 030 with a 16 bit bus
<geist>
but also i think you can simply wire up a board that only does 8 bit transfers and the cpu will just deal with it
<geist>
so probably that's the best idea for getting started
<mrvn>
You can buy an amiga board, or at least pre-order from the next batch they make. But then you need to buy the custom chips for it too.
<geist>
yah there's someone locally selling an amiga 500 for i think $300 but that's too much
srjek has quit [Ping timeout: 268 seconds]
gildasio has quit [Remote host closed the connection]
<mrvn>
way cheaper, better but some assembly required.
gildasio has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
gildasio has quit [Remote host closed the connection]
<mrvn>
One of the custom chips probably handles the bus.
gildasio has joined #osdev
<geist>
yah
<geist>
an asic would have not a lot of trouble with it
<geist>
as a side note i think the 486 bus is roughly as complicated. one *could* build a fpga or whatnot to deal with one
<geist>
just folks dont get too nostalgic about 486 homebrew computers
<geist>
or at least without just using existing chipsets
<geist>
well maybe a it more complicated. a 486 is roughly contemporary with an 040
<geist>
386 maybe to an 020/030, and it has a fairly straightforward bus
<mrvn>
but more like below 68000 in capability and speed
divine has joined #osdev
<geist>
well, capability a 386 is clearly intended to be a competitor to the 030 (i think 030 was first)
<geist>
but performance wise, yeah. dunno at what mhz they were equivalent
<mrvn>
A 040/060 at 50MHz rivals a P90 easily.
<geist>
i'd be a little doubtful of that, but have no good way to verify it
<mrvn>
FPU wise maybe not but integer performance of m68k is way above x86
<geist>
that sounds possibly right. the FPU of a pentium was definitely a jump forward for x86 line
<mrvn>
Ram wise my Amiga had nearly double the throughput to a P90.
<geist>
yah was thinking that: if it had a solid 50Mhz bus that would be pretty good. there were some mystical 50Mhz 486s in the day that were coveted for that reason
<geist>
had a proper fast bus, before most of them were reduced to 25/33 mhz busses
<mrvn>
Phase5 CPU boards where just amazing. You get 60+MB/s from normal ram while a P90 with EDO ram only has ~36MB/s.
<geist>
but then by the time a P90 came out (1994) it would have outclassed it by a long shot
<geist>
if nothing else because it was many years later, had a 60mhz bus, etc
<geist>
ah possibly yeah
<mrvn>
I think P90 usualy had 33MHz bus-.
<geist>
what i duno is what the pipeline of an 060 looks like
<geist>
i thought so too but just looked it up and it said 60. but that actually doesn't make any sense
<mrvn>
I only remember it had some, was superscalar.
<geist>
yah wikipedia and other ones say the whole P54 line was 50-66mhz bus, depending
<mrvn>
probably only with expensive motherboards
* geist
shrugs
<geist>
anyway, 68k was a pretty good competitor until it just stopped competing
<mrvn>
and comodore ruined the Amiga
<geist>
by late 90s it was starting to get seriously outclassed. motorola wasn't keeping up
<clever>
from what ive heard, the major power for the amiga was all of the hw accel outside of the cpu
<mrvn>
that was a big part of it
<geist>
right, definitely the case with the early amigas, which were fairly slow cpu wise, but didn't matter
<geist>
or at least fairly slow in that they weren't special
<geist>
ie, mac had similar cpu, etc
<clever>
the pistorm guys have even been trying to replace the m68k in a mac with an rpi
<mrvn>
Amigas where used for video editing a lot, even years past their prime because they could perfectly sync to the CRT and do special effects in sync.
<clever>
but a lot of the rom stuff is based around amiga
<mrvn>
mac? I thought the pistorm boards where for actual amigas.
<geist>
there was a generic processor card slot there for a lot of the macs, and folks have been making upgrades there left and right
<clever>
pistorm can basically replace an m68k cpu, in anything that used an m68k
<clever>
you just have to adjust how the kickstart rom and zorro3 cards are working, to suit the new motherboard
<geist>
yah, if there's a slot that's basically the bus all you really need is a card to get to the right pinout
<mrvn>
and bus protocol
<clever>
during boot, the reset vector is somewhere around 0 or 4 i think
<clever>
and the kickstart rom is mirrored from its normal addr to 0
<mrvn>
4 is the address of the exec.library
<clever>
and from there, it will jump to the proper addr of the KS rom
<mrvn>
I think reset is 0.
<clever>
and then the rom can instruct the mapper chips to turn the mirror off, so ram gets mapped to 0
<clever>
but now you have the question, how does the mapping get changed? what addr is the rom actually at?
<mrvn>
copying the rom to ram and reseting is actually a great way to speed up your amiga.
<clever>
does mac and amiga use the same mechanism?
<clever>
mrvn: but that also requires patching the rom, because of a lot of absolute addressing
<clever>
in the case of emu68, it can optionally accept a KS rom via the initrd path in the rpi bootloader
<clever>
and then it emulates the rom in "fastram"
<mrvn>
it's a well established practice. don't think there is actually that must copying going on since all the access is relative to the library base address.
<clever>
so any requests to the rom, get directed to the pi's dram
<clever>
but you still also have to deal with the zorro3 cards
<clever>
its kinda pci-ish
<clever>
where you can configure each expansion card in order, reading the size of its features, and assigning an addr
<mrvn>
I think it's more PCIe-ish. pci was a step back in flexibility.
<clever>
emu68 will hijack attempts to do that with the motherboard, and inject its own expansion cards first, then let requests go thru to the motherboard
<clever>
from what i heard, its more pci then pcie
<clever>
out of reset, all cards are in a no-op mode
<clever>
and via a daisy-chained signal, you put the 1st card into config mode, and it will appear at a fixed addr
<mrvn>
way better than ISA and plug&play (and way before plug&play)
<clever>
you can then inspect its config, and set its final addr, and tell it to enter normal mode
<clever>
and the daisy-chained signal will then cause the next slot in the system to enter config mode
<clever>
so you can repeat the process
<clever>
unlike pci, you cant change the config afterwards, like how the pci config space is accessible forever
<clever>
and one of the things you can map, is an expansion rom
<clever>
which gets executed during boot, and can mutate the library system
<mrvn>
but how often do you want to do that? It's not like you first boot into 16bit mode and the bios configures it, then 32bit mode and the bootloader configures it and then 64bit mode and the kernel configures it.
<clever>
yeah, it also had no need to reconfigure things
<clever>
emu68 uses virtual zorro3 cards to inject a device-tree and sdhost driver into the system
<clever>
so your SD card shows up as a standard hard drive
<geist>
re: reset, i think 040 (or maybe 030) can remap it
<clever>
and other drivers can query the DTB that the firmware passed in
<geist>
there's a control register with the vector base address
<mrvn>
geist: yes
<geist>
but of course initial reset was at 0 i'm sure
<geist>
dont think there's a pin to strap it to something else
<mrvn>
geist: you boot, copy rom to fast ram, reconfigure the control register, reset
<clever>
in the case of emu68, the rom address is mapped to the rpi's dram, so your already in fast ram
freakazoid333 has quit [Read error: Connection reset by peer]
<mrvn>
Which also means you can copy a rom file from disk to ram and then reboot into it.
<clever>
oh, that reminds me about the whole kickstart floppy
<clever>
they basically shipped units before the rom was finished
<clever>
and included a battery backed sram card, to act as a rom replacement
<clever>
and on first boot, it would initialize it from floppy
<mrvn>
clever: the first amiga didn't have the rom at all. just a bootloader.
<clever>
yeah
<mrvn>
And not like PCs where you get a blinking "_" and then "no boot medium found". Nah, you get a graphical, animated prompt to insert the boot floppy.
<clever>
yep
<clever>
thats just showing off :P
<geist>
yah i remember seeing one of thse modern amiga fixit things and one of the upgrades is to add more roms that has kickstart already in it
<mrvn>
Only think they didn't have was heavenly music like MACs had.
<mrvn>
geist: there are also upgrade kits to have multiple roms with a little toggle switch to select.
<mrvn>
Like when you want an old ROM for some games that stopped working.
<mrvn>
Never saw much point in that myself. As soon as you have fast ram you want the rom in fast ram and then you can load it from anywhere. No rom needed.
<clever>
i dont know how exactly it works, but whdload somehow sets up VM's to deal with that
<clever>
allowing you to patch compatability issues
<clever>
and run different roms
<clever>
i think even x86 was doing similar, bios shadowing, where you cover the bios addr up with ram, and copy it over
<clever>
but modern bios are on spi flash, which becomes an actual bottleneck
<mrvn>
Any proper code doesn't care since all the library interfaces had versioned functions and backward compatibility.
<clever>
not a parallel rom directly on the same bus as everything else
<clever>
i also discovered that the pistorm guys also have irc, #pistorm
<mrvn>
here?
<mrvn>
(libera)
<geist>
yah i discovered the Rosco 68k thing has a fairly active Discord channel
<clever>
yeah
<geist>
lots of folks building boards for it, powering unices, etc
<geist>
porting
<clever>
> Even more bridged channels at : #pistorm-hardware #pistorm-amiga #pistorm-pi #pistorm-firmware #pistorm-chat
<mrvn>
geist: how much ram does your board have?
<clever>
mrvn: and a number of the discord channels are bridged, each to a diff room
<clever>
bbl
<geist>
1MB but i also ordered the 4MB expansion board
<geist>
just no chips, sicne there's some lead time on that
<geist>
it's just using straight SRAM so cant easily cram a ton of memory on it without a dram controller
<mrvn>
Nothing compared with the 130MB I have: 8-P
<geist>
using 512kx8 sram which i think are some of the biggest dips you can get for fairly cheap
<gog>
130MB of SRAM?
<gog>
nice
<mrvn>
2MB chip + 128MB 60ns SIMMS
<geist>
yah woud need dram to go faster
<mrvn>
or 50ns, can't remember
<geist>
OTOH that means the SRAM on this thing is probably zero wait state
<mrvn>
probably a lot faster than my chip ram since there is no gfx chip using half the cycles.
<geist>
yah that too
<mrvn>
chip ram is so slow you can convert chunky to planar at the speed of memcpy.
<mrvn>
You decode some mpeg2, convert yuv to 256 colors and the bottle neck is writing the frame to 8 bitmaps for the gfx chip.
<mrvn>
geist: does your board have the address/data bus exposed on some pin header? Can you add some extra boards like a graphics card?
<geist>
yeah
<klys>
which board are we talking about? r.pi4b ?
<geist>
looks like there's a lot of folks building custom addon boards
<geist>
rosco m68k. ordered one on tindie a few weeks ago
<klys>
ah thx
<zid>
could build it a 4 bit adder now, we have the schematic
<geist>
fun thing about 68k is it's still quite hobby osdev hackable
<mrvn>
it's fun to design a state machine for composite video in hardware. Just a bunch of counter register to trigger state changes and you have the hsync, vsync and data bits for greyscale composite output with a 16MHz clock.
<mrvn>
Does the rosco-m68k have an fpga on it?
<mrvn>
left top is the 68k. left bottom I guess is 4* ram. What are the 3 chips right top and the square thing right bottom?
<mrvn>
Is the square thing the UART?
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn>
*waiting for pizza, sigh*
<gog>
i don't wanna wait/for my pizza to be delivered/i want to eat right now/i'm so hungry
<papaya>
I feel that
<papaya>
waiting is the worst
<zid>
I want pizza money
<gog>
best i can do is 380isk
<zid>
eve or rl? :P
<gog>
rl :p
<zid>
I think I have like 10B in eve ISK, I don't think that's much pizza though
<kazinsal>
1b EVE ISK = 1800 RL ISK
<kazinsal>
based on napkin math of current PLEX prices
<zid>
£2.27 apparently, 380 ISK
<zid>
so I just need about 6x that much
<clever>
mrvn: thats also basically how all video outputs on the rpi work, the trigger points for each counter are just configurable
<clever>
plus an optional set of vertical params for the odd field
theruran has quit [Quit: Connection closed for inactivity]
<heat>
also a great reminder that I should boot the images in CI
orthoplex64 has quit [Quit: Leaving]
<mrvn>
heat: why not &phys_ranges[nr_phys_ranges] - &phys_ranges[index + 1]?
<mrvn>
or sizeof(phys_ranges[0])?
<mrvn>
Also: shouldn't you memmove? The ranges are overlapping
<heat>
the memcpy works because I'm copying back
<mrvn>
it's code that works but not correct code
<heat>
the C++ standard committee can submit a pull request if they so choose
<heat>
:P
<mrvn>
then you get nice std:Array and ranges or views
<heat>
>ranges
<heat>
nah thanks
<heat>
i'm good with, erm, normal arrays
<mrvn>
range checked operations are a lot safer
srjek has joined #osdev
<mrvn>
Wouldn't it be nice if the compiloer would warn about the previous code? sizeof(phys_range) should return a integer tagged as sizeof "memory_range*" and then warn about using a "memory_range*" size argument where a "memory_range" size argument was expected.
<mrvn>
Is that code parsing the memory map from x86_64 or riscv?
<heat>
it's generic code
<mrvn>
Are the memory infos for both archs that similar?
<heat>
erm, it's just memory?
<heat>
(start, end)
<heat>
or (start, size) if you prefer
<mrvn>
it's an array of entries describing memory regions.
<bslsk05>
github.com: Onyx/multiboot2.cpp at master · heatd/Onyx · GitHub
<heat>
i haven't found a need to describe memory regions further anyways
<mrvn>
hmm, that fails on some real hardware. mmap entries overlap
<heat>
I haven't found hardware that does that
<heat>
certainly not UEFI
<mrvn>
I had some. verry annoying.
<mrvn>
Had like a big chunk of 4GB available mem and then later in the middle of that a small entry reserved.
<Griwes>
I'm very tempted to just outright not support platforms that do that
<mrvn>
I think it was the PCI hole in the lower 32GB and the bios just added that as a unavailable entry without splitting up the available memory entry.
<mrvn>
lower 32bit
<heat>
that's not good but it's also something I could easily solve by doing bootmem_reserve
<heat>
it's really nice to have a stable bootmem facility for once
<mrvn>
I did 2 loops. First add all available ranges and then a second loop removing all non-available (if its marked available)
<heat>
boot is way more resilient *if I don't screw up memcpys*
<mrvn>
heat: I would still prefer sizeof(phys_ranges[0]) there instead of the type behind the array. I always fear that someday the array type could change and then it's broken again.
<gog>
lööp
<mrvn>
I wonder when gcc/clang will warn about the memcpy because it violates the restrict qualifier of the builtin type.
<mrvn>
I can't believe I'm saying this but I think I ate too much pizza. Can one eat too much pizza?
<bauen1>
mrvn: please don't overdose on pizza, that'd be very unfortunate
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Likorn has joined #osdev
<papaya>
overdose on pizza? no such thing
<zid>
depends how much heroin you have on it
<bauen1>
papaya: i'm sure there are at least several components in a pizza that is toxic at high enough concentrations, so this leaves the question if you can eat enough pizza to reach these levels before you experience too sever side effects from eating pizza that force you to stop