SBC-3. Current status

[faybs]

Great!

[faybs]

You know, speaking of jumpers, I was looking at your ATMega8 programmer at http://sbc.rictor.org/io/atm8prg.html, and it occurred to me that the ATMega8 in the SBC3 is almost ready to be updatable in-system. All you need is to be able to control its reset line independently of the rest of the system. I think that adding another three-way jumper that allows its reset line to be connected to either the reset circuitry or SS6 should allow that to happen. The jumper would also act as a "write protect" for the ATMega8.

[8BIT]

You are correct. However, since the ATM8 is being used for KB input to the system, it would be very risky to try to re-program it in-system. You may loose control of the keyboard and therefore prevent any further operation. You would not be able to issue reprogramming commands to put it back to its original state. Result: an unusable system.

You could use an alternate input device to control the system during programming.

You could also have a second ATM8 and use a small dongle with an ATM8 socket connected to one of the other SPI ports, connecting the reset pin of the ATM8 to the SS pin.

This would prevent loss of control for the cost of only a few dollars. Arranging alternate control would most likely cost much more.

The same thing goes for the EEPROM. You cannot write to it in-system. I did this to prevent unintentional overwriting of the OS. Again, for a few dollars in parts, you can build an EEPROM programmer that connects to a VIA and use a second EEPROM IC to experiment with.

I would prefer not to add the jumper you recommended... unless there are stronger reasons to add it.

thanks

Daryl

[faybs]

I was going to say that you still have the serial port, but that's in the ATMega too... yep, you'd be hosed if you kill the ATMega

[8BIT]

Oct 17 Update

I have almost finished the ATM8 kb processing code. I had to re-write some of it to remove the loops that were causing the ATM8 to not return to the SPI handling code.

Still debugging SBC-3 code that is not reading the ATM8 corrently. I think SBC-3 is too fast for the ATM8. I'll add some delays in the code to confirm.

After that, I'll get the RS-232 code tested and the XMODEM transfer also.

I've had to spend the last week and a half dealing with our son's school and was not able to devote time to this project.

I hate to say it, but I need to push the order date back again.

Current board requests are down to 11 + 1 maybe as one requestor (3 boards) has not responded. The cost may go up a few dollars unless I get more orders. It will still be below $30.

Daryl

[8BIT]

8BIT wrote:

I had included JP3 & JP4 to be used exclusive of one another. However, I like your idea of a 3 pin jumper. I spent a few minutes looking over the board and think it would be easier to use VIA1's CB2 as there's not room to add the needed traces near VIA2.

I'll leave P16 at VIA2's CB2 for future expansion or user choice.

Addition: I was able to remove JP3 & 4 and replace with a 3-pin JP3 to allow VIA1's CB2 to be sent to either J5 pin 12 or the ATM8's pin 28.

Pad P16 was left also.

Daryl

After diving into the 65SPI-ATMega8 communications this weekend, I encountered the major drawback to SPI. There is no efficient way to know that the slave is ready to respond to the Master's requests with the SPI hardware. An external line is required.

I had added a jumper to SBC-3 to allow the ATM8 to connect to CB2. Since CB2 can be an input or ouput, I decided to use CB1 (or CA1) instead.

I am going to tie a handshake out from the ATM8 to the CA1 or CB1 of VIA1 (jumper selectable) to allow for slave to master communication.

For the basic SBC-3 OS, it will only be polled. User's can modify the code if interrupts are needed.

I should be able to finish up the ATM8 and OS code in about 1 week. SBC-3 will then be ready. I'll post the updates after its all checked out.

Daryl

[kc5tja]

8BIT wrote:

After diving into the 65SPI-ATMega8 communications this weekend, I encountered the major drawback to SPI. There is no efficient way to know that the slave is ready to respond to the Master's requests with the SPI hardware. An external line is required.

This is why I said (in a different thread) that peripherals must have an independently running SPI controller, running completely asynchronously from the intended peripheral. This lets the SPI interface continue to run while the peripheral itself is busy doing other things, allowing it, at a minimum, to feed back a peripheral's ready-status to the master.

Code: Select all

Pros:
* No external line necessary.

* Simpler host construction.

* If a peripheral goes south, only that peripheral remains in the seized state.

* Permits the possibility of using interrupts for asynchony between the host and peripheral, as the readiness reading then merely reflects the interrupt state.

Cons:
* Each peripheral potentially requires two microcontrollers instead of one: one to service the SPI interface, and one to perform the intended task.

* Without the use of interrupts, the host would have to poll each peripheral for its readiness using SPI bus transactions, one per peripheral.  This has a software complexity cost.

With the external line approach, it would pretty much have to be an open-drain line, allowing any number of peripherals to assert it. The problem with this approach is that it is impossible to tell which peripheral is pulling it into busy state, so the entire bus is seized until all peripherals are ready.

Code: Select all

Pros:
* Simpler peripheral hardware, at the cost of minimal host hardware expense.

Cons:
* If any one peripheral says it's busy, the entire bus is locked from operation.  This can waste bus bandwidth.

* Impossible to tell [i]which[/i] peripheral is the busy one.

* If a peripheral goes south, your host goes with it.  :-)

* Interrupts can only tell you when the bus is free for use.

[8BIT]

I have the RS-232 code working on the ATMega8 and most of the keyboard code working. Still a few bugs to find.

In the mean time, I tested the RS-232 by uploading several images to the SBC-3, including a 6-frame animated gif (converted to the SBC-3 display format) and ran a simple loop, using the NMI vertical interrupt, to time a 6 frame-per-second video.

I put the video on youtube and have a link on my site.

http://www.youtube.com/watch?v=mNw6JZZv-oQ

Back to the debugger!

Daryl

[kc5tja]

Very nice! I wasn't aware your SBC could render graphics. That's very cool.

I've been playing around with the SEAforth-24A ForthDrive of late (see http://tinyurl.com/3pnavg), and I have it generating HSYNC and VSYNC signals to drive a VGA monitor, but that's as far as I've gotten. The VGA breakout board hasn't yet arrived, so I cannot test it with a real monitor yet. However, the o'scope shows all frequencies to agree with what's documented in my monitor's manual.

Here's hoping it works...

[8BIT]

kc5tja wrote:

Very nice! I wasn't aware your SBC could render graphics. That's very cool...

I'm not sure render is the proper term. I downloaded 6 static pictures into RAM and then used the Video Display register to select which image was displayed. This cycled through the 6 images at 6 frames per second.

When I think of "render", I think of the picture actually being generated in video RAM by a program on-the-fly. While I'm sure the 65816 has the horsepower to do that, the frame rates and complexity of the images has yet to be tested on SBC-3.

Your ForthDrive is similar to the Propeller in design, although the ForthDrive appears to have more horsepower. Good luck with your project. I've seen some neat video from those types of devices.

Daryl

[kc5tja]

8BIT wrote:

I'm not sure render is the proper term.

If it fetches bitmapped data from video RAM, it's rendering that to the screen.

Quote:

I downloaded 6 static pictures into RAM and then used the Video Display register to select which image was displayed. This cycled through the 6 images at 6 frames per second.

Yes, this is called "page flipping."

Quote:

When I think of "render", I think of the picture actually being generated in video RAM by a program on-the-fly.

That's one kind of rendering: where the program generates (renders) the bitmap data, though not necessarily on the fly. I remember many days waiting hours for my Amiga to render a ray-traced scene.

Your definition of render is too narrow.

[8BIT]

OK. I'll widen my definition . My main purpose was to clarify the fact that the images I generated were not done on-the-fly.

Daryl

[8BIT]

The draft copy of my SBC-3 User's Guide is on my website. Still debugging my ATMega8 code - but hope to have time this weekend to iron things out.

http://sbc.rictor.org/download/sbc3desc.pdf

Feedback welcome.

Daryl

[faybs]

This is good stuff!

I have a question, that just occurred to me: what's the recommended way for programs running on the sbc3 to detect if they're running on an ntsc or a pal system? This would be important knowledge for programs that use vblank interrupts as a timing source. If you haven't got a simple way of doing it yet, I'd like to suggest using bit 3 of the VDR as a read-only flag: 0=ntsc, 1=pal (or vice versa, whichever results in the least amount of work ).

[8BIT]

Sure. I'll add your suggestion.

0=NTSC, 1=PAL.

Thanks!

Daryl