Difference between revisions of "Gadget:Gen-X"
Jump to navigation
Jump to search
| Line 33: | Line 33: | ||
* The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register). | * The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register). | ||
| − | * Auto-alignment rules are brain-damaged: the assembler will re-align instructions but not their associated labels, and won't even warn you if constants are mis-aligned. | + | * Auto-alignment rules are brain-damaged: the assembler will re-align instructions but not their associated labels, and won't even warn you if constants are mis-aligned. |
| + | ** Ha! The -align option forces natural alignment of data. This fixes most of the problems. Just be sure to manually re-align after any byte data. | ||
Revision as of 02:07, 30 June 2023
Getting Started
- Both displays show logos, but only display B is responsive.
Startup
- On hard-reset, the FPGA copies the first 64k of flash to $0.
- Post-upload reset leaves that block alone, so you can upload code there.
Documentation
- The Gen-X on the 68k side appears to be an A2560K; preliminary documentation is Here.
- The Gen-X on the 65816 side appears to be an FMX.
Memory
- MOVE16 presently only works with the SRAM in the first 4MB.
- Confirmed ... can't burst from flash either.
- This basically means you can't cache anything anywhere else.
- Ugh. Burst writes don't seem to be reliable (they appear to be getting out of sync); burst reads appear to be working.
- Stef says to avoid using the DRAM for now.
- Because the MMU makes all of its fetches using burst mode, for now, its tables must be in SRAM.
- The MMU will not dcache table entries, but it can lock up if tables none-the-less end up there. Motorola recommends avoiding this scenario by disabling caching on MMU table memory. If this is not possible (as presently on the Foenix), they recommend disabling either the MMU or the dcache during table updates.
- IMHO, an easy solution here (so long as you're only using the MMU for access control) is to hard-code the tables after the vectors and otherwise avoid touching them. If you /do/ need to touch them, statically alias them somewhere else in memory, and mark that region no-cache.
I/O (68k)
- Power and SD Card LED control bits at GAVIN:0000 (feca) don't appear to work.
- LFSR registers must be accessed in 32 bit mode.
- The I/O space should be marked as serialized/no-cache (defaults to unserialized -- reads can get ahead of writes).
vasm
- The 68040 MOVEC cache and MMU control registers are there, but typically without the last letter (R for Register).
- Auto-alignment rules are brain-damaged: the assembler will re-align instructions but not their associated labels, and won't even warn you if constants are mis-aligned.
- Ha! The -align option forces natural alignment of data. This fixes most of the problems. Just be sure to manually re-align after any byte data.
