What kind of throughput are we talking about?

I'm sorry, but I just don't see what the problem is. Interrupts or not.

At the fastest speed a 65816 is documented to run, 20MHz, to emulate a 1MHz signal on a bus, you need only 4 to 5 NOPs in between writes to a VIA. With each NOP taking 2 cycles, that results in 10 cycles in between writes to the VIA. It takes two writes to the VIA to produce a 1MHz square wave (one for signal low, one for signal high). The total number of cycles, assuming proper tuning will equal (or come close to) 20 cycles. 20MHz / 20 cycles = 1MHz.

What am I missing?

Regarding the FPGA write buffer approach, note that modern PCs have have used this technique for years to eliminate wait-states from programs which write data into video frame buffers. This is, in fact, precisely the reason why you now render graphics in core memory first, then copy it blindly to a video card's memory space. As soon as you read from the video card space, you have to wait for a complete I/O round-trip to finish, which introduces wait-states. As long as you restrict yourself to just writing, and you have deep enough buffers, and you can keep the CPU busy between writes (which is easy enough to do on multitasking systems and inside games), you can update the hardware asynchronously to the I/O device without incurring any wait-states.

Where was this question originally asked?

I don't think this can be answered -- it depends on the project.

If I manage to finish my Kestrel-2 design, I'd just use the Swinsid as it exists now, perhaps using another ATmega chip to interface to the 65SPI interface and drive the Swinsid's bus interface.

so ,if the speed is not a problem then why not to make some super i/o chip , with spi , i2c , rs232 ...etc . ? using single mpu chip.

I don't know what you're after here, but you can make the VIA put out a square wave on PB7 running off of T1 without any attention from the processor. My workbench computer has an option to feed the 16X RxC clock input of a 65c51 ACIA from a VIA's PB7 to get the 31.25kbps bit rate for MIDI. If this is too off-topic, just disregard.

GARTHWILSON : you are of topic

I think I might have confused swinsid for this device:

http://roboterclub-freiburg.de/atmega_s ... gaSID.html

It has source code but does not fully emulate the SID.

Still, I'll have to read more about the swinsid.

Daryl

Why the speed of swinsid is a problem ? .
I my project I'm using nmib to generate 50hz interrupts to play sid's at right speed . each time the nmib is low I need to slow the cpu speed down to 1mhz , and that works fine . But , my vga subsystem generates irq every time the vertical line counter is at 0 . and here is a problem . Playing sid's at 1mhz takes a lot of the raster time , that makes some difficulties . Imagine situation when we need to start some fragment of the code when raster is let's say at line 100 , then comes nmib ... any ideas, how to sort this out ??

Ah, that's it. Playing sounds while doing raster-interrupt work. Many games on the C64 did this actually very well, with a 1MHz CPU. You might consider looking into these games.

IMHO there are two options with a 1MHz CPU, both would not use the NMI to trigger sound output though:

1) synchronize the sound output with the screen vertical interrupt, or
2) accepted the jitter introduced in the sound output due to the raster interrupt having higher priority.

The vertical interrupt is different in Europe and the US though (50Hz vs. 60Hz), so the sounds on some games on the C64 had a different speed in Europe and the US.

As for the jitter, how long is your raster routine? And I mean the critical section that must immediately be done? Let's assume 100 cycles, that would be 0.1ms @ 1MHz, if you immediately after the raster routine critical section do the sound output if necessary. Not sure if the human ear detects that kind of jitter, maybe you know more here.

With a faster CPU: if the raster interrupt routine runs much shorter than the critical section time and the sound output fits into the critical section time as well, you can use the NMI. For a 20MHz CPU the 100cycles from above would use 0.005ms, so if the sound output routine is less than 0.095ms (or 1900 cycles @ 20MHz) you could still use the NMI and fit sound and raster routine into the critical section time of 0.1ms. Note that you only have to slow the CPU down to 1MHz using SID writes, not during the whole sound routine. A SID access then takes 20-40 cycles @ 20MHz though (up about 20cycles jitter due to clock synchronization between 1MHz SID and 20MHz CPU). You have to take that into account when calculating your numbers.

But if the CPU is not fast enough to handle the raster routine and the sound within the critical section time, you would still need to make the raster interrupt a higher priority than the sound interrupt. Assuming the raster interrupt must absolutely not be interrupted. Then you would still have the jitter in the sound output, but maybe smaller than before (as the raster routine may be faster with a higher CPU speed).

If you absolutely not want to interrupt the raster routine, and absolutely want to do sound output at exactly the cycle of the timing signal (now your NMI), then you could either use two CPUs that run independently and can serve each interrupt at exactly the correct time. Or you could queue the writes to the SID (data + register value + next wait time) in a hardware queue, that would write this to the SID at the correct time. The queue could be filled in by the CPU at a non-criticial time. IIRC the MIDI stuff uses such a queuing approach, although much more elaborate of course.

I can only give you options, but you have to evaluate them against your requirements and pick your solution.

André

Hi , just few words to take the mess away .


Right .. but VIC generate irq in c64 at 50hz (In the pal versions) . so ,what you have to do is execute song playing routine after you do all of your raster jobs . In project's with vga the raster irq will be around 60hz . So what we need to do to play sid's ? a separate source of 50hz . Correct ?

Swinsid chip wont work when the bus speed is faster then 1mhz . It's possible to play songs which includes playing routines at faster bus clock , but not without changing them ( to produce some delay between writes to swinsid registers) .

Thats for sure , my idea for now is to add that code to nmi and irq routines :
does it have any chance to work ?

The whole story was about to ask Swinkels to implement his project to some chip which will be able to work with faster bus speed. He is multi-talented guy , and I sure he can do it , but I think he wouldnt do it just for me.

Ps . Another thing is :a lot of people are interested in T65 core ,
why not to put all brains together and implement this core with spi , i2c ,rs232 in single fpga chip ? . Cores are free and available in the internet .

But many 65xx systems are constructed to slow down the bus for slow peripherals. The CPU speed, most of the time, can be much higher, and will be slowed down when accessing swinsid, probably just for a few cycles per audio sample.

Yep. We'll probably use an on-fpga i2c interface to debug our T65 work, when we get back to that project. (An on-fpga "logic analyser" buffer should allow us to see what's going on and going wrong.)

On a related note, if you made any changes to get your T65 up and running, please post your patches!

Cheers
Ed

Yes, but many systems use slower chips, that are fed with a slow clock. When the faster CPU accesses the slower chip, the fast CPU has to use wait states, but the slow chip only sees the slow clock.
Examples are the SID in the CBM 600/700 series, my 65816 boards run with a very fast 65816 with on-board RAM, but slow down to access the 1MHz system bus (that never sees the fast clock), not sure if the C128 had the same problem with the SID, I'm sure there are other examples.

What that does is actually interrupt the raster job with the NMI routine, which is about 17 cycles (NMI 7, LDA 2, STA 2 - assuming Zeropage, RTI 6). If your raster job can handle such a delay randomly in the middle of the routine, ok.

Your raster routine has a handicap now though - your NMI routine changes the accumulator. You most likely want to add a PHA/PLA wrapper in the NMI routine (increasing the delay. Remember, the 6502 does not automatically store its registers on interrupt). Otherwise you would not only have to protect the raster job from AC being modified, but all code that needs to run while your NMI code above can be called (i.e. even outside your IRQ routine)

Also there is a (possible, though unlikely) race condition. If the NMI occurs between the LDA #$00 and the STA 50hz_Rdy. Only happens if your raster job is longer than a screen, so most likely not happening at all.

Why not change the interrupt lines? Use IRQ for the sound and NMI for the raster job? That makes the raster job run at the correct time, which is your highest priority as I understand.

Using the NMI always is a very tough thing though, it makes even IRQ routine timings unpredictable, and needs well thought-out synchronization with non-NMI routines to avoid race conditions, therefore it is very often avoided.

Using an IRQ for your timing requirements is another challenge though. You could, in the beginning of your IRQ routine check if it's a raster job and start it if yes. If it's a sound interrupt, you'd have to clear the interrupt line and do a CLI, to allow for a raster interrupt.

So I'd rather use the NMI for the raster job and the IRQ for the sound output.

André

Thanks for the replay !.

The code i have wrote is only example , my irq routine is much biger .
hmm , i will thing about this . Thanks for your advice.

Hi Guys

I have finish my DOS with fat32 on atmega32 and sd card .. and now I have thinking about to take next step . So ... sprites . In my sbc , screen resolution is 320 x 384 in 256 colours . So each sprite with let say 32x48 res. in 256 colours need 1.5kb of ram memory . I can't imagine to animate 16 of them in single raster pass (moving or changing 24kb of ram) . The reason for that funny resolution is because that keeps nice proportions (makes nice box) . So do anyone of you has some experiences , suggestions or anything else what can put me on the right way ? I can't relay make those sprites smaller , is the only way to reduce the ram usage is to reduce the sprite colour's ? . Or maybe bank switching ?

The way the Commodore-Amiga's Agnus and Denise chips handled sprites might be of interest.

The sprite shifters could be stuffed with data at any time, even by the CPU if it wanted. Generally speaking, though, DMA was used to fetch data from sprite memory. Each sprite had its own DMA channel.

Each sprite had two registers which controlled where it appeared vertically on the screen. The first register was a raster-compare register that, when it matched, turned that sprite's DMA channel on. The second register was a raster-compare register that turned the DMA channel off. Thus, a sprite could actually be as tall or as short as you wanted it.

(Where the sprite appeared horizontally was controlled by a single horizontal position register.)

Hope this helps.