Thread
Soft ps mod for hard ps macs & apple II's
No, they use an overlay function. the ROM overlays RAM during the first startup procedure, For interrupts sake. Then once the ROM boots up so far, it goes back to its original spot, and the program counter advances to where ROM is supposed to be.
If the Quadra series was reading ROM from the slow-poke access time ROMs, NO WONDER my Radius 33 ran rings around them, Radius was licensed to run the Rocket with the ROM images copied into RAM on its local bus!
Did the SE/30 PDS accelerators read the ROMs across the PDS too?
Galumph . . . galumph . . . galumph . . . galumph . . . galumph . . . :
Did the SE/30 PDS accelerators read the ROMs across the PDS too?
Galumph . . . galumph . . . galumph . . . galumph . . . galumph . . . :
Yes, it is called a race condition. I don't know where logic trap came from.
bingo. thats the term I was thinking of. lol. I remember using concepts like that for getting code out of protected microcontrollers.
Here's my n00b question for the day:
There was discussion earlier about a microcontroller listening on the bus, decoding addresses and data accesses, and the problem with figuring out when to read these without having to sync clocks. I'm reading over the Designing Cards and Drivers book, and with the 030 PDS (I don't know if it exists on other machines), couldn't you use /AS to trigger reading a GPIO register hooked to the address lines, and /DS to trigger reading the corresponding GPIO register for data? That means the microcontroller needing to decode every bus access, which is high overhead, but would it work? It seems like some discrete logic to decode addresses for the microcontroller so it didn't have to decode every access could reduce the microcontroller's workload in this scenario?
Anyway, it is my understanding that when /AS is low, the address lines are valid, and the same thing for /DS and data lines, so assuming you could read in those lines before they are no longer valid, it seems like you could accomplish the goal without caring about the clock.
There was discussion earlier about a microcontroller listening on the bus, decoding addresses and data accesses, and the problem with figuring out when to read these without having to sync clocks. I'm reading over the Designing Cards and Drivers book, and with the 030 PDS (I don't know if it exists on other machines), couldn't you use /AS to trigger reading a GPIO register hooked to the address lines, and /DS to trigger reading the corresponding GPIO register for data? That means the microcontroller needing to decode every bus access, which is high overhead, but would it work? It seems like some discrete logic to decode addresses for the microcontroller so it didn't have to decode every access could reduce the microcontroller's workload in this scenario?
Anyway, it is my understanding that when /AS is low, the address lines are valid, and the same thing for /DS and data lines, so assuming you could read in those lines before they are no longer valid, it seems like you could accomplish the goal without caring about the clock.
I dont have that book. Only book I have is designing cards and drivers for the macintosh II and Macintosh SE.
But I see your point and it does make sense. a peripheral card HAS to know when the Address/Data bus has settled and can be read.
But I see your point and it does make sense. a peripheral card HAS to know when the Address/Data bus has settled and can be read.
/AS == Address Strobe, and /DS == Data Strobe. They appear to be standard 680x0 signals, so the 68k manual should document memory bus accesses, I'd imagine. /AS should be low once the the address lines are all settled and there is a valid address on the bus, and same for /DS for the data lines.
Well, for /DS, if the R/W line indicates a read, it means the peripheral should be putting a valid address on the bus. For writes, a valid address should already be on the bus.
Well, for /DS, if the R/W line indicates a read, it means the peripheral should be putting a valid address on the bus. For writes, a valid address should already be on the bus.
I wonder if /AS and /DS is bi-directional? if the CPu is doing a read from the card, the CPU would pull /AS low, then the card would output the data with the card pulling /DS low. Maybe?
Designing cards and drivers:
My understanding is the the bus master (the one controlling the address lines) should be the one driving the /DS signal.
Here's the 68030 data sheet which documents memory bus access: http://datasheets.chipdb.org/Motorola/68030/MC68030.pdf
My understanding is the the bus master (the one controlling the address lines) should be the one driving the /DS signal.
Looking at the timing diagrams beginning on page 28, its kinda confusing a little bit.
The Synchronous read and write bus operations, I could clearly go off just the /AS /DS R/W and the /DBEN signals by themselves if you wanted to, as they ensure the address and or data is valid at the time these signals get asserted. But again, the listening MCU would have be at least 4 times the speed of the bus/CPU. I guess this is why just about every expansion card back in the day had a CPLD/FPGA or glue logic. an AVR wouldnt be bad because its a near 1 to 1 execution to clock ratio but the max speed a standard AVR goes up to is 20mhz.
The Asynchronous reads and writes are way different, have to pay attention to the falling edge of the clock to get the proper data bits. nothing really else to look for that I can see.
The Synchronous read and write bus operations, I could clearly go off just the /AS /DS R/W and the /DBEN signals by themselves if you wanted to, as they ensure the address and or data is valid at the time these signals get asserted. But again, the listening MCU would have be at least 4 times the speed of the bus/CPU. I guess this is why just about every expansion card back in the day had a CPLD/FPGA or glue logic. an AVR wouldnt be bad because its a near 1 to 1 execution to clock ratio but the max speed a standard AVR goes up to is 20mhz.
The Asynchronous reads and writes are way different, have to pay attention to the falling edge of the clock to get the proper data bits. nothing really else to look for that I can see.
Hows progress?
I havent really anything helpfull to add, I'm still following this,
i havent lost interest - especially in an apple IIGS version
from what i read, i understand correctly technight, that you like the idea of having a mcu basically being capable of controlling the softpower and kb startup/finder shutdown for most hardpower mac models excluding the mac+ and earlier(and hopefully the IIGS - had to add that ) all on one chip?
I havent really anything helpfull to add, I'm still following this,
i havent lost interest - especially in an apple IIGS version
from what i read, i understand correctly technight, that you like the idea of having a mcu basically being capable of controlling the softpower and kb startup/finder shutdown for most hardpower mac models excluding the mac+ and earlier(and hopefully the IIGS - had to add that
) all on one chip?
yup as soon as I find some time. been busy lately with side-repairs and at work.
Cool
Would you be willing to intergrate a non-software boot function of the mcu for what was discussed earlier with trash80tohpmini earlier for 8 bit apples? - pressing down reset button for a soft boot and press and hold reset for a few seconds to powerdown?
as the os (prodos) is only a simple cli.
Tho having said that, if a register is provided. Using 8 bit 'appleIIDesktop' would become way cooler, with a simple shutdown app writing to the register shuts down the machine when the a2desktop gui (its not a full os , just a desktop that sits on top of the os.
Another thought, maybe also u could - if it is a simple matter - only for completeness later on maybe, u could program ur mcu to respond to a simple keypress combo for early macs eg apple delete or something,as long as the finder doesnt own tht key combo, it could be used to hard shutdown the system fter the shutdown menu item has been run. just a few ideas...
Would you be willing to intergrate a non-software boot function of the mcu for what was discussed earlier with trash80tohpmini earlier for 8 bit apples? - pressing down reset button for a soft boot and press and hold reset for a few seconds to powerdown?
as the os (prodos) is only a simple cli.
Tho having said that, if a register is provided. Using 8 bit 'appleIIDesktop' would become way cooler, with a simple shutdown app writing to the register shuts down the machine when the a2desktop gui (its not a full os , just a desktop that sits on top of the os.
Another thought, maybe also u could - if it is a simple matter - only for completeness later on maybe, u could program ur mcu to respond to a simple keypress combo for early macs eg apple delete or something,as long as the finder doesnt own tht key combo, it could be used to hard shutdown the system fter the shutdown menu item has been run. just a few ideas...
i know nothing about the apple II line. :-(
key combos would require you to be able to decode the ADB system. the power button on an ADB keyboard is a separate line.
key combos would require you to be able to decode the ADB system. the power button on an ADB keyboard is a separate line.
oh interesting! the reset/power key is separate!
in the 3rd paragraph i was refering to early macs without adb or the power key.
in the 3rd paragraph i was refering to early macs without adb or the power key.
but it was just an idea. Not that it was my idea, but i realise i might have come across as pushy. I apologise for this, sorry mate.