Difference between revisions of "Gadget:Gen-X"
Jump to navigation
Jump to search
| Line 16: | Line 16: | ||
* MOVE16 presently only works with the SRAM in the first 4MB. | * 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. | ** This basically means you can't cache anything anywhere else. | ||
| − | |||
* Stef says to avoid using the DRAM for now. | * Stef says to avoid using the DRAM for now. | ||
| + | * Because the MMU makes all of its fetches using burst mode, for now, it's tables must be in SRAM. | ||
| + | * Extreme caution is required if the MMU tables are in memory that can be cached (Motorola strongly recommends that you not do this). As a result, when using the MMU, caching can't be bulk-enabled on the first 16MB; MMU tables will be required for cache control, limiting caching to a dynamic 512 byte window. Ugh. | ||
I/O (68k) | I/O (68k) | ||
| Line 29: | Line 31: | ||
* 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. Thus, be sure to re-align after any inlined byte tables. | ||
Revision as of 13:37, 28 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.
- Stef says to avoid using the DRAM for now.
- Because the MMU makes all of its fetches using burst mode, for now, it's tables must be in SRAM.
- Extreme caution is required if the MMU tables are in memory that can be cached (Motorola strongly recommends that you not do this). As a result, when using the MMU, caching can't be bulk-enabled on the first 16MB; MMU tables will be required for cache control, limiting caching to a dynamic 512 byte window. Ugh.
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. Thus, be sure to re-align after any inlined byte tables.
