|
|
Last visit was: Wed Jul 09, 2025 2:19 pm
|
It is currently Wed Jul 09, 2025 2:19 pm
|
rf68000 - 68k similar core
Author |
Message |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2384 Location: Canada
|
Bug Fixes The trace flag was being reset by the TRAP instruction preventing tracing through traps. TRAPS were skipped over. This might be the behavior desired most of the time. In many cases one does not want to step through OS routines that are assumed working.
Crashes Stepping through code crashed when stepping through the keyboard routines. This crash will likely not be fixed. The keyboard routines are needed by single-step; it is pretty obvious they cannot be single-stepped at the same time they are being used. There should be an option to skip over subroutines. It is tempting to add the skip into the CPU hardware. The trap flag state could be stored as the LSB of a subroutine address on the stack when a subroutine call occurs. It could then be restored.
Mods Added rotating destination cores for interrupts to the interrupt controller. This was to support staggering of the timer interrupt. The idea is to prevent all cores from trying to manipulate system lists at the same time. The timer interrupt was adjusted to occur more often so that the interrupt period remains the same for each core.
_________________Robert Finch http://www.finitron.ca
|
Mon Jul 07, 2025 4:27 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2384 Location: Canada
|
A lot of finagling trying to get the timer ISR running for FMTK. Not having much luck. The default tick interrupt works great, but the FMTK timer ISR is somewhat larger and more complex. It has a launchpad written in assembler, then the bulk of the ISR is C code. One thought was that perhaps it was consuming too much time, so I tried increasing the period of timer interrupts, setting them to 33 Hz instead of 100 Hz. The CPU is not particularly fast by today’s standards. No luck.
The timer ISR was modified to store registers in the task control block (TCB) instead of on the stack.
Added two instructions to the CPU using up two illegal opcodes. Store register list to task control block (sttcb), and load register list from task control block (ldtcb). Then got rid of the instructions. Storing to the TCB can mostly be done with a movem generic instruction.
Re-wrote the demo graphics routines in the boot program in C instead of assembler. Triggering the graphics routine demo causes a crash now. It is desired to move as much code as possible to ‘C’ instead of assembler. But the C routines seem to not work as reliably as the assembler code.
_________________Robert Finch http://www.finitron.ca
|
Tue Jul 08, 2025 7:00 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2384 Location: Canada
|
The FMTK timer ISR appears to be working, but does not update the on-screen IRQ live indicator. The IRQ flag for the interpreter is being set, and the tick count is incrementing, viewed using the monitor’s memory dump command. On a hunch, the IRQ live indicator was re-written to load and store the screen value using a register intermediary. Previously it just did an ADD directly to memory. The difference is that the ADD to memory is a read-modify-write operation whereas using the register it is separate a read and write. It is uncertain whether read-modify-write operations make it through the bus bridge and the I/O device. Timer ISR is fixed now.
DRAM memory reads were busted for non-streaming reads. Generation of the ack signal was faulty.
Non-streaming reads are still broken. Spent some time tweaking the MPMC (multi-port memory controller) to fix reads. Managed to simplify some logic a tiny bit. Non-streamed reads now appear to work. Tens of KB of data were dumped from the DRAM without a crash. Previously it would crash after about 8kB.
Updated the memory controller with more support for cached reads. The controller now latches the read request until it is filled. Previously the cache was completely pipelined. In theory cached reads should now work. (Seemed to work in sim). Just testing now (turns out not to work). Cached reads are a bit convoluted. A read miss goes into a miss queue while the read is stalled until the miss gets a chance to update the cache. It could be some time before there is a response on a miss. There may be outstanding misses from other channels to process before the current miss. There may be some more work required on the LRU updates. It looked like it may be updating too many slots in sim. Having too many slots updated reduces the effective associativity of the cache.
_________________Robert Finch http://www.finitron.ca
|
Wed Jul 09, 2025 10:05 am |
|
Who is online |
Users browsing this forum: claudebot, facebook crawler and 0 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|