BIOS for the 65C816?

[Ruud]

BigDumbDinosaur wrote:

Actually, you completely agreed with me.

Re-reading your message I see that I read it wrong (haste ?). So I completely agree :)

[Dimitri]

Ruud wrote:

I would make use of a prooven concept: vectors. It is used in CP/M, DOS and by Commodore. The OS should be completely hardware independant.

That is what I am thinking a BIOS with a hardware independant OS and software ontop. All the "drivers" of a modern system are handled by the BIOS and in the hardware itself instead of in the OS. To allow the greatest protability of the system possible. Allowing a hobbiest to use a unified Software platform on various 65C816. Which would make it useful for educational instutitutions and the like for supporting the CPU which would lead more interest to the platform.

Ruud wrote:

My idea: if it can be altered, why not load it instead?

Wouldn't that just increase the boot time? If your going to load the bootloader first then load the BIOS, couldn't you just make the BIOS part of the OS?

kc5tja wrote:

There are two other wonderful features of this too, which often gets overlooked:

1. You can bootstrap the OS from a serial EEPROM, which are much easier to program and much cheaper to acquire.

2. You can use a relocatable binary format, allowing you to re-use the same BIOS (or OS) image at different locations in memory, depending on your hardware's specific memory map.

That is pretty neat using more EEPROM to load the OS as well. I didn't think of that, was too focused on FLASH and magnetic memory to think about it.

BigDumbDinosaur wrote:

My earlier suggestion was to copy the required part of the ROM to RAM and run in RAM only.

I will definately be doing that. Due to the fact I want to run as quickly as possible on this system while it remaining stable.

Dimitri

[Ruud]

Dimitri wrote:

Wouldn't that just increase the boot time?

A bit, we are talking about a few KBs.

Quote:

couldn't you just make the BIOS part of the OS?

If you are talking about one single file, yes you can. But it certainly is not advisable. One (of many) valid reason: it allows you to place the BIOS in a completely different area of the RAM then the OS.

Quote:

That is pretty neat using more EEPROM to load the OS as well. I didn't think of that, was too focused on FLASH and magnetic memory to think about it. :oops:

Ehhhhh, Flash = EEPROM: http://en.wikipedia.org/wiki/Flash_memory

[Dimitri]

Ruud wrote:

One (of many) valid reason: it allows you to place the BIOS in a completely different area of the RAM then the OS.

Thanks for the responce.

Ruud wrote:

Ehhhhh, Flash = EEPROM

I realize that, but I keep FLASH as programable memory storage that can be done by the host system. Verses EEPROM which is strictly a remove from the system and reprogram affair for the most part. One can be reprogrammed on the fly, the other cannot.

The OS needs to be possibly be reprogrammed for hopefully not Microsoft's reasons sometimes by the OS itself (updates) or by the user (adding functional parts to it). And the user shouldn't have to use a EEPROM programmer to do it with.

Dimitri

[8BIT]

EEPROM's can be reprogrammed in system - my SBC-2 could do it. There are two things to remember:

1) You need to have the /we pin connected to the proper logic (not tied to Vcc)

2) The program that executes to write the EEPROM must be located in a different device than the one being programmed. RAM for instance or a second EEPROM chip if your system has more than one. The reason is that while a byte is being programmed in EEPROM, the EEPROM canot be read properly, so any program trying to execute from it will get corrupted results.

I can explain further and provide example code if needed.

Daryl

[ElEctric_EyE]

Daryl, I would love to see your efforts in programming a EEPROM/FLASH! Especially ones larger than 512Kx8.

I'm currently having compatibility problems programming large FLASH's, because I am depending on the G540 Programmer. It has been nice programming everything up to a 512Kx8 flash...

Very recently I've searched for other programmer's. They do not fill the need either.

There are some very nice (i.e. large/fast) FLASH devices available out there. However, common programmers are incompatible.

One that I've checked out just this past week is the SST39VF1681,82.
http://ww1.microchip.com/downloads/en/D ... S71243.pdf . It's a 2Mx8 FLASH. Can it be programmed using the tools you have used?

Maybe we can start a new thread?, I didn't mean to derail the OT...

[Dimitri]

Post in this thread if you wish, this is a discussion group and as dicussions go, sometimes they are fuild like this one and one thing leads to another and the topic changes. No one here gets upset about side tracking threads I hope.

In this case the topic is changing for the best, off topic or not I'd be interested to see the EEPROM programming information as well.

Dimitri

[8BIT]

OK. EEPROM writing is not complicated. I will use the Xicor 28C256 32Kx8 EEPROM that I used on my SBC's for this example.

From the datasheet, I decided to use the polling method. When you write a byte to eeprom, it starts an internal process. During this time, reading the same location will return with bit 7 inverted and bits 0-6 will be "indeterminate". So you simple write the byte then read it back and compare it to the original byte and loop until they match. Block mode writing works the same way but I just used the single byte write method.

Here's a snippet of my SBC-2 code:

Code: Select all

Move_cmd1      INC   Addrptr           ;  increments addrptr
               BNE   Move_cmd2         ;
               INC   Addrptr+1         ;
Move_cmd2      inc   Hexdigits         ;  "M" cmd code
               bne   Move_cmd3         ;
               inc   Hexdigits+1       ;
Move_cmd3      SEC                     ;  checks if range done
               LDA   Memptr            ;
               SBC   Addrptr           ;
               LDA   Memptr+1          ;
               SBC   Addrptr+1         ;
               BCC   Move_brk          ;  exit if range done
               jsr   Scan_Input        ; see if brk requested
               bcs   Move_brk          ; 
               LDA   (Addrptr)         ;  Moves one byte
               STA   (Hexdigits)       ;
               BRA   Move_cmd1         ; (zapped after move from eeprom_wr)
EEPROM_TEST    lda   (Addrptr)         ;    moved along with Move_cmd for EEPROM_WR
               eor   (Hexdigits)       ;    ""
               bmi   EEPROM_TEST       ;    ""
               bra   Move_cmd1         ;    ""

This is ROM code that is used to move a block of memory starting at Addrptr and ending at Memptr to Hexdigits. These are all zero-page pointers.

To write to eeprom, I would copy this routine to RAM, replace the BRA move_cmd1 command just above the EEPROM_TEST label with NOP's and then call Move_cmd1.

The EEPROM Test would EOR the original byte with the EEPROM's byte and loop until they matched.

That's it. Hope this helped. Ask any questions. I have not used any FLASH memories or EEPROM's larger than 32Kx8, so I really can't help too much with those.

Daryl

[HiassofT]

8BIT wrote:

I have not used any FLASH memories or EEPROM's larger than 32Kx8, so I really can't help too much with those.

But I did (128kx8 and 512kx8), and it is not too complicated.

I'm currently working on a kind of generic flasher-library (I called it "libflash") for the Atari 8bits. So far it works with several flash-cartridges that bank in a 8k or 16k block of flash into memory.

My idea was to provide a higher level, abstracting from the bank-switching and - as far as it's possible - from the flash chips.

The API provides high-level functions where you provide a linear 24bit address to read/write/verify either several bytes or serveral pages of the flash chip.

Erasing the whole chip is also quite generic, but of course when you want to erase a block/page of the flash you need to check for the exact flash type before.

This is still work in progress and there are several hacks in the code which are not too optimal (for example hard-coded 8k/16k banksizes to increase performance, supporting carts with 2 flash chips or carts with battery-backed RAM instead of flash). Also some in-depth documentation is still missing (there are a few comments in the code and some general usage instructions in "libflash.inc").

Currently the code works with AMD 29F010, 29F010B, 20F040(B), ST 29F010B, 29F040B and BM 29F040.

These flashes all work more or less identical: you send a special signature to the chip and then can program a single byte or erase a block (or the whole chip).

I have some other code here (which still needs to be incorporated into libflash) which also supports SST 29EE010 and Winbond 29EE011. These Chips work slightly differently, they are organized in 128 byte blocks. You can't program just a single byte of the chip, but only 128 byte blocks.

Here's the link to my current code:
http://www.horus.com/~hias/tmp/libflash-101204.zip

All the code is in ATasm format, it uses some macros, labels starting with a "?" are local labels.

"libflash.inc" is the main header/definition file, "libflash.src" the base flasher code and "libflash-xxx.src" is the cartridge specific (bankswitching- and initializing-) code. "flash.src" is a simple flasher program using the libflash code.

If something's unclear, just ask!

so long,

Hias

[Ruud]

Maybe some of you noticed, I'm busy designing my own 65816 system on an ATX board. I have worked before with the 65816 but so far only as a direct replacement for the 6502. I wrote programs for such a 65816 equipped system but only small ones. And I'm not familiar with the use of "long" instructions at all.

Looking for some code I could use as example, I ran into this thread. The reason I revive it is that, so far, I didn't find any. I found BDD's POC projects and Daryl/8bit's SBC-x projects but no sources (or did I miss them completely?). So any pointers are still welcome!

[BigDumbDinosaur]

Ruud wrote:

Maybe some of you noticed, I'm busy designing my own 65816 system on an ATX board. I have worked before with the 65816 but so far only as a direct replacement for the 6502. I wrote programs for such a 65816 equipped system but only small ones. And I'm not familiar with the use of "long" instructions at all.

Looking for some code I could use as example, I ran into this thread. The reason I revive it is that, so far, I didn't find any. I found BDD's POC projects and Daryl/8bit's SBC-x projects but no sources (or did I miss them completely?). So any pointers are still welcome!

On my POC website, you can find a listing for the complete firmware (although out-of-date). There is also a listing for Supermon 816. The latter, as well as the monitor portion of the firmware, uses 24-bit addressing to fully access the (theoretical) 16MB address space. Click on DOWNLOADS on the left side of the screen.

It may surprise you a bit to find out that use of "long" addressing is actually uncommon in many 65C816 programs. In many cases, setting DB to the target bank and using 16-bit addressing is more efficient, both in terms of cycle consumption and code size. In the realm of long addressing, the two most useful addressing modes are [<dp>] and [<dp],Y, both of which use a 24-bit, direct page pointer to touch the entire address space. When coupled with a 16-bit index, the 65C816 sees the full extent of RAM, ROM and I/O as a flat address space.

More '816 information may be obtained here and here.

[Ruud]

BigDumbDinosaur wrote:

Click on DOWNLOADS on the left side of the screen.

I feel dumb, I completely missed that. Thank you!

Edit: Just what I was looking for. Thank you very much!

Quote:

More '816 information may be obtained ....

And thank you again!

[BigDumbDinosaur]

Ruud wrote:

BigDumbDinosaur wrote:

Click on DOWNLOADS on the left side of the screen.

I feel dumb, I completely missed that. Thank you!

Just use my excuse.