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

_________________

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.



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?



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.



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

A bit, we are talking about a few KBs.

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.

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

_________________

Thanks for the responce.



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

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

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...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

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:



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

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

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

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


And thank you again!

_________________

Just use my excuse.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!