The vsync bit mirrors the vsync logic inside the counters. It is active during the three lines of the vsync period.

Since I was short on pins, I am sending a composite sync signal to the AD724. It is an exclusive OR of the H sync and V sync logic.

I will experiment with adding registers.

As an option, I can look at larger chip with more capacity.

Have to go now, we have a family crisis. Will be back next week.

Daryl

I'm back. A personal message to the forum follows:


Now, back to my SBC-3 core. I was unable to simply add the Vertical IRQ. I will experiment with swapping a few pins to see if I can make it work. I was able to give up one pin in order to have an IRQ on the 84 pin PLCC.

Having a line compare register IRQ is not going to happen with the 84 pin PLCC. There's not enough resources left. The 100 pin QFP can as it has more gates and IO pins to work with.

Daryl

First, my sincere condolences. Both my parents still live, but I have lost a few close friends over the years.

Next, the PLCC package is more hobbyist friendly because even though PLCC is surface mount, one can buy cheap sockets with a reasonable 0.1" pitch. If the QFP package also has a .1" pitch then it's probably OK, but if the pitch is 1mm or less then soldering the 100 pins is going to be a monumental, error prone chore. Given the choice, I'd rather give up the irq.

Thanks!

Yes, the 100 TQFP package has .5mm pin centers. I'm still working on being able to provide a Vertical IRQ. Seems my current package layout is really pushing the limits of the 95108.

Daryl

I was able to swap two pins and tweak some of the logic to get a Vertical retrace IRQ. It would be best to connect it to the NMI as it is a fixed length pulse that cannot be reset (acknowledged).

I now plan to start work on more of the IO block, along with building the text generation code and font data.

Daryl

I've finished writing the text to pixel routine. It has basic control character support - DEL, BS, CR, LF, TAB, and FF (Clear the screen). Font is fixed with white on black. It can be expanded to support color and alternate fonts, but this was written primarily to provide text support for the System Monitor.

I have updated the SBC-2 Monitor to support the 65816 opcodes in the disassembler. It allows memory dump, memory edit, block move and insert, list (disassemble), execute, and xmodem download to the entire 512k RAM area. I removed the mini-assembler... I may add it later.

The System monitor now resided in memory from $00E000-$00FFFF. It puts the 65816 into native mode, clears RAM, and jumps into the Monitor. A BRK instruction will dump the 65816 registers and return to the monitor. User programs in bank 0 can return to the Monitor with the RTS command while programs executed in higher banks need to use the RTL command to return to the Monitor.

Next up is to expand the IO to provide 65C22, RS-232, CF storage (FAT16 compatible), and ethernet support. The XR16L580 is working great. I found an Exar dual UART in a 40 pin DIP package that I will most likely use in the final design.

A simple suite of graphic routines is on the list too. I have written a Quickbasic program to convert a standard 320x200x24bit BMP file to one that can be dumped to the SBC. I will also work on supporting onboard conversion of BMP,GIF, and JPG files once the CF storage is working.

I am still using the TASS assembler for the time being. I have implemented a set of macros that provide the 65816 opcodes. I still plan to research other assemblers that natively support the 65816.

Daryl

Here is an update on development.

I have built an IDE interface using an Atmel ATMega32 microcontroller. On the IDE port I have a 32BM Compact Flash card. Larger cards can be supported as well as hard drives. The device must be formatted as FAT16.

I have been working on the FAT16 drivers and am about 75% completed.

Currently, I am using an RS-232 connection to my PC for testing. These are the supported commands so far:
VL - Volume Label
LD - List Directory
CD - Change Directory
MD - Make Directory
CN - Rename File or Dir
ER - Erase File or Dir
EA - Erase all Files in Dir
MF - Make A New File in Dir
RF - Read File
(Still need to add)
FP - Set File pointer (for random access)
DF - Format Drive
DM - Mount Drive (allows you to swap CF cards or select a different partition)
DD - Dismount Drive (close open files and close drive)

Current limitations include working only on Partition 1, DOS 8.3 file names, moving only one directory level at a time, and operating on one file at a time. I plan on supporting up to 16 open files. Sequential and Random file access will be supported as well. Still working on multiple partition support. Long File names will not be supported due to Copyright issues.

The final interface to SBC-3 is still open. I may use the serial ports on the 65C22's to create two unidirectional data paths or build an SPI interface. Another option is to port the controller code to 65816 and connect the IDE bus to the SBC-2 bus through buffers.

Here are the options to weigh: use the ATMega32 and offload the FAT16 processing but be limited in file handles, or put the IDE on the system bus and let the 65816 do the FAT16 processing and have greater file flexibility.

Once the test unit's firmware is completed, I'll post detail on my website.

Daryl

Could you descibe why the file system would be more limited if it were handled my the ATMega32?

Thanks!

_________________
Thanks for playing.
-- Lord Steve

Daryl, I was wondering if you're aware of this project: a DIP 40 module that implements tile and bitmap graphics, with hardware sprites, up to 256 colors and several different video modes. It has 32KB of internal VRAM and outputs to composite video. One communicates with it either via a TTL level RS232 or an 8 bit port with handshaking.

http://www.propgfx.co.uk/forum/Blah.pl?b-PL/

The project's still at the prototype stage, but as far as I know they're still taking suggestions for features.

Wow. That's a nice setup. I have read only a little about the Propeller chips but they sound very powerful. I'll keep them on my radar.

Thanks

Daryl

Sorry for not answering sooner... I missed this question.

The limitation is 16 open files max. If you used the 65816, you have more RAM to allow more open file buffers.

If a 16 file limit is more than enough for your applications, then there would be no limitations.

Daryl

You are storing the filebuffers in the ATMega's on chip RAM?

_________________
Thanks for playing.
-- Lord Steve

Not exactly.

I have one 512 byte RAM buffer for file IO, one 512 byte RAM bufffer for the FAT table IO, and 256 bytes for pointers to open files that takes up 16 bytes each (16 open files max). However, each time you access a different file, any data written to the previous file must be written back to the media. This will slow throughput and increase "wear" (write cycles) on the media.

Yes, the file and FAT buffer could be combined to save RAM but with a further reduction in throughput.

On the 65816, you could afford to have a 512 byte buffer for each open file, along with the FAT table buffer, and pointer storage. With 512k of RAM, you could have more than 100 files open easily within one 64k block of RAM. This would enhance throughput and save "wear" on the media.

My design is based on the C code from this project:
http://www.circuitcellar.com/avr2004/DA3670.html

However, the C version uses up a lot of RAM and won't fit into an ATMega32, so I have re-written it in Assembly. So far, I'm using 83% of RAM and only 30% of program memory.

As a side note, by removing the Format media code and combining file and FAT buffers, it might be possible to squeeze the code into an ATMega8 for use with a SD/MMC card. That would be a very small package. I have to finish the CF code first though.

Daryl
"I wish I had more free time!"

It's time for an update.

I have received 15 requests so far, and will continue to take requests until the boards are actually ordered. Thanks to everyone for waiting patiently.

I have moved the IO down to the first 49 bytes of memory ($00000-$00030), having weighed the arguments for keeping RAM as contiguous as possible.

I have also added an option to make the 4k of RAM from $0F000-$0FFFF write protected, under software control. Power-on and reset state is in protected mode.

The board has been layed out and I'm cleaning up a few things, and checking the netlists for any oversights. I will be able to get a production board (silk screen and solder mask) for $25.

I need to finalize the 65SPI firmware and write the ATMega8 code.

I have updated my website with more info. It's not complete, but I'm working on it. There is a parts placement diagram and list of materials, for those interested.

I'm still shooting for the end of September for placing orders, as long as my spare time does not dry up.

I will include the pre-programmed XC95018, XC9572, 28256, and ATMega8 in the package. I can also do a bulk order on the AD724 from Newark to help cut cost and shipping, for those interested. My kit cost is still to be determined, but is estimated at $70 with the AD724. The remainder of the parts should run about $90 from WDC and Digikey.

I would offer a complete kit of parts, but my budget is not big enough to front the costs.

Daryl

Thanks for the update!

There's one thing that has me scratching my head about the new specs though: I remember that PAL C64s and Amigas used to run just a tad slower than the equivalent NTSC machines (NTSC C64:1.02 MHz, PAL C64:0.985MHz; NTSC Amiga 500:7.15909 MHz, PAL Amiga 500: 7.09379 MHz). Both C64s and Amigas had a system clock that was derived off the display dot clock. Your design, on the other hand, also bases the system clock off the dot clock but has PAL systems running 22% faster than NTSC ones (8.715MHz vs 7.159MHz). What gives?