Last visit was: Sat Jul 31, 2021 6:12 am
It is currently Sat Jul 31, 2021 6:12 am



 [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
 CS01 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Managed to get the date/time from the I2C RTC. But am still stuck on getting a MAC address from either the RTC or onboard eeprom.

_________________
Robert Finch http://www.finitron.ca


Sat Feb 29, 2020 4:13 am WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
What is this "MAC address" you speak of? I've used I²C a fair amount and never heard of a MAC address in that context, so I looked it up on wikipedia and it also says nothing about a MAC address.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Sat Feb 29, 2020 4:24 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
My post was a bit succinct, it may have been unclear to some people.
MAC address not part of I²C . It’s data stored by an I²C memory chip.
MAC stands for Media Access Control. The MAC address is the network address of a device, often an ethernet controller. Each controller has a globally unique address. In order to get an address for the media controller (ethernet controller) in the system one is retrieved from a small eeprom which has been pre-programmed with a unique address as data in its memory.
In my system there are actually two sources of MAC addresses and I can’t get either of them to work.
Without a MAC address it’s not possible to connect to the ethernet. It is possible to manually assign one by hand (hard code it) but it’s better to use a MAC coming from a known source.

_________________
Robert Finch http://www.finitron.ca


Sun Mar 01, 2020 3:37 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Found out why the MAC address from the RTC wasn’t valid. The particular version of the RTC chip doesn’t support a pre-programmed MAC address. duh :oops: , upon reading the specs more carefully. The eeprom is still returning all zeros which makes me think the address is wrong.

_________________
Robert Finch http://www.finitron.ca


Mon Mar 02, 2020 4:17 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Added a triple mode redundancy feature to the multi-port memory controller. It may now read and write to three different areas of the ram. During readback a majority logic gate combines the three values read into a single read value.
There are issues with the system crashing due to bad return addresses. The system seems to work intermittently.

_________________
Robert Finch http://www.finitron.ca


Tue Mar 03, 2020 4:58 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Not sure what I’m doing with OS garbage collection. Momentarily I have the JAL and JALR instructions automatically clearing a garbage collect flag in the same manner an exception would clear the interrupt enable flag. With the flag set garbage collection is allowed. The idea is to disallow garbage collection in function prologues because it can create false garbage collection requirements. So, after the prologue is finished the garbage collect flag is set, enabling garbage collection. It works somewhat like an interrupt disable / enable feature as an eret will automatically restore interrupts while an interrupt automatically disables them.
Setting the garbage collect flag after the function prologue is done is done by code emitted by the complier to set the flag.

The TMR memory cycles didn't resolve issues with crashing on bad return addresses.

_________________
Robert Finch http://www.finitron.ca


Wed Mar 04, 2020 4:34 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
The latest project revision is to use the Petajon (CS01) processor in an FPGA carrier card mounted on a board that provides svga video and keyboard / mouse ports. I was going to post a pic of the routed board but the colors are garish. So, I’ve been working on designing a circuit board. The board uses an ISA AT form factor. It was a toss up for a while as to what form factor to use. I plan to use the board as the "console" board in a computer.

Still haven't figured out the crashes. Some progress was made by including better interrupt nesting depth checking. If interrupts get nested too deeply they are ignored. In order for this to work BIOS and OS function returns have to be primed by setting the return register value to 'E_TooDeep' *before* calling the function. That way if the ecall fails the return status is sitting in the register.
Code:
   ldi      $v0,#E_TooDeep
   ldi      $a0,#$401                  ; home cursor
   ecall
; check for E_TooDeep here

_________________
Robert Finch http://www.finitron.ca


Sat Mar 07, 2020 4:11 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Playing with the CS01 project. This post is relevant to the small version of the system running on a small xc7a15T FPGA (10,000 LC's) It’s a little further along than some of the other projects and I’ve got into the software for it more. Tonight, I managed to get serial output working using the FMTK multi-tasker. Serial input almost works too. I managed to capture a trace of a serial character input going through the serial IRQ routine and being placed in a buffer. So, the character is in the input buffer, it just a matter of retrieving it correctly. To retrieve a character of input the running app (in this case the monitor) must have the input / output focus. If the app doesn’t have the input focus then attempting to get a character returns a status of none available.

The cpu core has been updated with an additional integer register file for interrupt processing. That makes three integer register files, one each for user mode, machine mode, and interrupts. Having a separate interrupt register file simplifies some of the OS software and greatly reduces the interrupt latency. No need to store registers when an interrupt occurs. And interrupts can occur if the OS is running.
Code:
; On incoming the register file has been set to the interrupt register file
; or the machine mode register file.
;------------------------------------------------------------------------------
   code
   align   4
IRQRout:
   csrrw   $t0,#$342,$x0         ; get cause code
   bltz   $t0,.isIRQ        ; irq or ecall?
   ldi      $sp,#$80000-4      ; setup machine mode stack pointer
   jmp      OSCALL               ; goto operating system call dispatcher
.isIRQ:
   and      $t0,$t0,#31         ; interrupting device # is low order 5 bits of cause code
   sll      $t0,$t0,#7            ; 128 bytes per device func table
   add      $t0,$t0,#DVF_Base+22*4   ; load IRQ routine vector from device func table
   ldt      $t0,[$t0]
   beqz   $t0,.noIRQ       ; make sure there's an address to go to
   ldi      $sp,#$7F800-4      ; setup interrupt mode stack pointer
   jmp      [$t0]                  ; jump to the IRQ routine
.noIRQ:
   eret

The above code pulls a pointer to the IRQ routine to invoke from the device driver table.

The following is a table of planned device support. 32 devices should be lots of room. Tables which are statically allocated for devices don’t take up too much room.
Code:
;Standard Devices are:

;#      Device               Standard name

;0      NULL device          NUL      (OS built-in)
;1      Keyboard (sequential)   KBD      (OS built-in)
;2      Video (sequential)      VID      (OS built-in)
;3      Printer (parallel 1)   LPT
;4      Printer (parallel 2)   LPT2
;5      RS-232 1            COM1   (OS built-in)
;6      RS-232 2            COM2
;7      RS-232 3            COM3
;8      RS-232 4            COM4
;9      Parallel xfer     PTI
;10      Floppy               FD0
;11      Floppy               FD1
;12      Hard disk            HD0
;13      Hard disk            HD1
;14
;15
;16      SDCard               CARD1    (OS built-in)
;17
;18
;19
;20
;21
;22
;23
;24
;25
;26
;27
;28      Audio                  PSG1   (OS built-in)
;29
;30   Random Number      PRNG
;31      Debug                  DBG


The following are vector numbers for device operations.
Code:
; Device command opcodes
;
DVC_Nop            EQU      0
DVC_Setup         EQU      1
DVC_Initialize      EQU      2
DVC_Status         EQU      3
DVC_MediaCheck      EQU      4
DVC_BuildBPB      EQU      5
DVC_Open         EQU      6
DVC_Close         EQU      7
DVC_GetChar         EQU      8
DVC_PeekChar      EQU      9
DVC_GetCharDirect   EQU      10
DVC_PeekCharDirect   EQU      11
DVC_InputStatus      EQU      12
DVC_PutChar         EQU      13
DVC_SetPosition      EQU      15
DVC_ReadBlock      EQU      16
DVC_WriteBlock      EQU      17
DVC_VerifyBlock      EQU      18
DVC_OutputStatus   EQU      19
DVC_FlushInput      EQU      20
DVC_FlushOutput      EQU      21
DVC_IRQ            EQU      22
DVC_IsRemoveable   EQU      23
DVC_IOCTRL_READ      EQU      24
DVC_IOCTRL_WRITE   EQU      25
DVC_OutputUntilBusy   EQU      26

_________________
Robert Finch http://www.finitron.ca


Sun Aug 30, 2020 3:32 am WWW

Joined: Mon Oct 07, 2019 2:41 am
Posts: 255
Two SDC cards would be better than two floppies. Front panel is allways handy.


Sun Aug 30, 2020 7:15 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
I have to agree floppy drives are outdated. I like your suggestion of a front panel device too.

Difficult to find bug: the serial I/O wasn’t working because the SerialGetChar routine was checking head and tail pointers from user level code. The pointers are located at physical address $9800, $9804. When viewed in the logic analyzer the addresses accessed were $4C00 and $4C04. This had me going for a while because $4C is one half of $98 meaning it looked like the address was shifted by a bit to the right. I spent a lot of time trying to debug where the address was being shifted. Then I finally realized it was likely the physical address assigned to virtual address $9800 in user level code. I switched the code to calling the routine from machine mode and it was fixed. The issue had nothing to do with shifting.

Character input is closer to working. Every third character is recognized for serial input.

IO is so simple without an OS. With the OS in place, the cpu executes hundreds of lines of code to put a character to the serial port. The OS must check that the current task owns the serial port device before allowing the I/O. All the I/O management takes place in machine mode using physical addressing, so user level code can't really access the I/O other than to request access from the OS.

_________________
Robert Finch http://www.finitron.ca


Mon Aug 31, 2020 3:42 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Added a user level CSR to contain the garbage collection interrupt enable bit. For code running at the user level only, a subroutine call will automatically disable the garbage collector interrupt. The interrupt must then be enabled after the function prolog is complete. Enabling of the interrupt is ignored by code not running at the user level. This is so that a routine may be written to operate any level, and it won’t inadvertently enable an interrupt while running non-user code.

_________________
Robert Finch http://www.finitron.ca


Tue Sep 01, 2020 2:54 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Switched from using the subroutine call, to using the addi instruction to disable GC interrupts. This is going to be switched to a custom instruction ‘alloc’ in the near future. The name ‘alloc’ was changed to ‘gcsub’ to avoid conflicts.
Trying to debug what was wrong with the serial routines. There was a constant $F streaming to the serial port. Well it turns out a while ago I put a debug line in to output the hex code of the character of serial input. Turns out it was displaying this correctly as $FF (-1) meaning no char available. It works when there is no char available, but with chars it returns 0 when it should be returning the char code. Don’t know if this is a buffering issue or not.

_________________
Robert Finch http://www.finitron.ca


Thu Sep 03, 2020 4:17 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Mostly more debugging today. Had fun for a bit before I realized that serial port interrupts were enabled. I wrote a little code to peek the serial port and echo it back. Of course it didn’t work properly with interrupts enabled. The receive interrupt would store the char in a buffer then the peek wouldn’t find anything.
Also put a second timer on the via6522 to work as the garbage collect interrupt timer.

_________________
Robert Finch http://www.finitron.ca


Fri Sep 04, 2020 4:10 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
More debugging. I found out why every fourth character was ignored by the serial. It turns out that the memory interface module to the static ram onboard was faulty. It didn’t always write out the correct bytes. Strangely, writing out words and some other values worked. The memory interface bridges between an eight bit wide sram and the 32-bit processor bus.

_________________
Robert Finch http://www.finitron.ca


Sat Sep 05, 2020 5:25 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Debugging has been challenging. The system monitor is running as a user app and so doesn’t have access to the OS memory. It’s interesting then to get dumps of OS memory to try and figure out what’s going on. An OS call has been implemented to be able to report the status of PAM bits for instance. I need to figure out how to get the monitor to run at the machine level.

_________________
Robert Finch http://www.finitron.ca


Sun Sep 06, 2020 6:01 am WWW
 [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: CCBot 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

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software