Last visit was: Thu Jul 31, 2025 3:15 pm
|
It is currently Thu Jul 31, 2025 3:15 pm
|
rf68000 - 68k similar core
Author |
Message |
oldben
Joined: Mon Oct 07, 2019 2:41 am Posts: 817
|
robfinch wrote: Milestone: the OS is switching between two threads. <- this is busted now
Mods: Added a simple trace facility to the CPU core. It tracks the last 2048 PC addresses. When a button is pressed on the FPGA board, the trace buffer gets dumped and appears in the logic analyzer. The trace facility does not work as expected, it is dumping only a single address.
The serial port driver was finally fixed up for new semaphore operation.
The IRQ priorities were flipped around for the serial port and keyboard. Serial port is now number 5 and keyboard is number 3. This gives the serial port a higher priority. Cereal port, needs to be 7. Breakfast is a important meal.  For testing could the the keyboard also have break key irq that bypasses the normal irq handler?
|
Fri Jul 25, 2025 3:15 pm |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
Quote: Cereal port, needs to be 7. Breakfast is a important meal.  For testing could the the keyboard also have break key irq that bypasses the normal irq handler? Level 7 is reserved for NMI on the 68000 it is wired to a button. I have the timer on 6. Thought about detecting CTRL-ALT-DEL in hardware and having it trigger a higher interrupt. CTRL-C is detected in the keyboard IRQ handler and causes the current program to abort and jump to the monitor. There are only six IRQ signal levels. I wrote some code to allow chaining multiple ISRs to an single IRQ level, but it is ugly. For now, there is just a single ISR per IRQ signal level.
_________________Robert Finch http://www.finitron.ca
|
Sat Jul 26, 2025 3:41 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
ModsAdded support for the TAS instruction at the memory. In theory the RMW cycle of TAS can be performed atomically. Using TAS instead of hardware semaphores allows more semaphores to be implemented, as any address may become a semaphore. The semaphore lock and unlock functions were altered to accept an address instead of a semaphore number. The system is busted ATM. It runs for a second or two then crashes. It has something to do with switching to a thread I think. The PC gets corrupt somehow. The thread switching is simple. 1) disable interrupt 2) save regs in thread control block 3) switch to kernel stack 4) acknowledge interrupt 5) call 'C' ISR (may change the active thread control block) 6) restore regs from thread control block Code: _FMTK_TimerISRLaunchpad: move.w #$2700,sr ; disable interrupts
; Save register context in TCB move.l a0,-(a7) ; push a0 movec.l tcba,a0 ; a0 points to task control block movem.l d0-d7/a1-a6,4(a0) ; save registers in task control block move usp,a1 ; save usp in TCB move.l a1,60(a0) move.l (sp)+,64(a0) ; pop a0 into TCB move.w (sp)+,140(a0) ; status reg move.l (sp)+,136(a0) ; program counter move.w (sp)+,144(a0) ; and format word move.l a7,68(a0) ; finally save a7
move.l #$47FFC,a7 ; setup sp
; Reset timer IRQ ; We know which irq it must have been, would not be in this routine unless ; it was the right one. lea PIT,a0 move.l #16,$1010(a0) ; write flag value to negate irq,underflow flags move.l #$1D000000,$FD260014 ; reset edge sense circuit
; Display IRQ Live indicator movec.l coreno,d0 lsl.l #2,d0 lea.l $FD0000DC,a0 move.l (a0,d0.w),d1 ; fetch colors from screen movec.l coreno,d2 clr.w d1 or.w d2,d1 ; or in core number add.l #$10030,d1 ; add ascii '0' move.l d1,(a0,d0.w) ; move to screen
; Call 'C' interrupt handler jsr _FMTK_TimerTickISR ; call the IRQ routine
; Restore register context from TCB. Note that a different context may be ; restored than the one saved. movec.l tcba,a0 ; a0 points to task control block move.l 60(a0),a1 ; restore usp move.l a1,usp movem.l 4(a0),d0-d7/a1-a6 ; restore register set move.l 68(a0),a7 ; restore a7 move.w 144(a0),-(sp) ; push format word move.l 136(a0),-(sp) ; push program counter move.w 140(a0),-(sp) ; push status reg move.l 64(a0),a0 ; restore a0 rte
_________________Robert Finch http://www.finitron.ca
|
Sat Jul 26, 2025 3:52 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
Looks like the issue with switching threads is fixed. The supervisor stack for each thread was the same, the fix was to make them separate. Now there is an issue with getting keyboard input from the monitor.
_________________Robert Finch http://www.finitron.ca
|
Sat Jul 26, 2025 5:58 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
The IOFocus variable used to determine which core has the I/O focus gets corrupted somehow. This causes the I/O focus to be lost preventing keyboard input and causing display issues. For now, the I/O focus is reset in the monitor’s loop waiting for a keyboard character. This allows things to work, except that core #2 always has the focus.
Milestone: Sending a message from one thread to another waiting for a message.
_________________Robert Finch http://www.finitron.ca
|
Sun Jul 27, 2025 3:51 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
Mods
With message send/receive looking like it is working, the way the keyboard works was changed. It now uses message primitives. All the ISR does is post a scan-code to the keyboard mailbox. A Keyboard translate thread then translates the scan-code and sends it to the App with the input focus.
The system monitor was changed to use a mailbox to receive messages. It sits in a loop waiting for keydown messages from the keyboard translate thread. And… it does not work. The system hangs.
Removing the keyboard translate thread allows the system to work, although without keyboard input. This thread was given a higher priority than the other threads.
Modified the memory controller to allow a port to use both streamed and non-streamed access. Access is differentiated by the transaction id which is always zero for a streamed access and non-zero for non-streamed access.
_________________Robert Finch http://www.finitron.ca
|
Tue Jul 29, 2025 4:10 am |
|
 |
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2401 Location: Canada
|
Bug Fixes CheckMsg() was not unlocking the mailbox and message at one return point. Issues The system is trying to add a thread to the timeout list that is already on the timeout list causing a panic. There are only a couple of possibilities. 1) A flag is not being set indicating the thread is timing out 2) The thread is not properly removed from the timeout list
SendMsg() and PostMsg() are very similar. It is tempting to try and combine them into a single call. The difference is SendMsg() may cause thread rescheduling and PostMsg() does not. Also, SendMsg() will block until the message can be sent, whereas PostMsg() will wait only a short time, returning a busy error if the message cannot be sent succinctly.
There are two fields (srcadr and dstadr) in a message block that are not being used. They may be eliminated. The idea was to track where the message came from and where it was going. Removing the two fields would make messages 16 bytes in size.
Messages are not currently timestamped or tagged with co-ordinates. What type to use for graphics co-ordinates? Mods Streamlined SendMsg() and PostMsg() by removing redundant code. They were allocating a message, then freeing same message if a thread was dequeued from a mailbox. Now the message is not allocated or freed in that case.
Modified the message primitives to send and receive a pointer to a message rather than the individual message fields. Setting up the individual message fields would result in too many arguments. The message type was modified to include a timestamp and graphics cursor co-ordinates.
_________________Robert Finch http://www.finitron.ca
|
Wed Jul 30, 2025 4:13 am |
|
Who is online |
Users browsing this forum: claudebot, PetalBot and 155 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
|
|