Landover BBS - Commodore 128 & PET - since 1987

Hi!

I know how to use CIA timer and TOD in assembler...

Main problem is that it's RESETted after pressing STOP+RESTORE....

The TOD clocks in the CIAs are not affected by Stop/Restore.  Once started they free-run as long as power stays applied.  Only a hard reset will stop the TOD clocks while power is applied.

To start a stopped (or stalled) TOD clock simply read the tenths register and immediately write it back.  This can be accomplished from BASIC or M/L.

Erm, sorry if I ask, but with all these problems, why are you want to use this thing? If this device has no or bad C128 compatibility, no JiffyDOS compatibility, no 1571 compatibility, difficult installation, curious usage... when I read all the threads about this thing it looks like it's either total crap or only usable on a un-modified C64.

You probably shouldn't believe everything you read on the Internet.      The RA unit works fine on a C-128.  In fact, I have a 128D here with an RA connected to it and it works fine.  As for JiffyDOS compatibility, why would you need it with the RA?  The RA' DOS is far beyond what JiffyDOS can do.

And what makes it so much better than a CMD HD or a 1541 Ultimate to live with these incompatibilities?

• Much higher performance than either of the above devices.
• Minicomputer-like DOS, with far greater capabilities that either of the above.
• Multiplexing capability, which allows multiple C-64s or C-128s (any combination) to share the same drive.
• Keyed random access.  Using keyed random access, one can build databases with tens of thousands of records, and be able to retrieve any one record in about 250 milliseconds.  Try that on a floppy disk, Bubba.

Where is possible to get Rear Admiral DOS & HDD?

That I don't know.

But my artistic and design skills are on a par with those of a spastic monkey - ie none at all.

That makes you a Picasso compared to me.

Bugger - my mistake, was fiddling with the settings and accidently left some 0's off it

Good thing your boss didn't leave a few zeroes off your paycheck!

So me an DeeKay are having a conversation about VIC-II sprites.  In particular, a *feature* called sprite-crunching.  He gave me a reference to a document by the VICE team.  This covers some of the missing details of the "VIC-Article" by Christian Bauer. 
 
Anyway, the VICE document refers me to US Patent# 4572506.  Somewhat informative but very confusing.  I have a degree in Electronics Engineering and also have considrable experience with the VIC-II.  Yet this document is still extremely difficult to read.  Good luck to anybody without a heavy technical background...
 
So instead of trying to read lawyer / nerd mumbo-jumbo excuse for the English language, I thought it would be easier to simply look at the schematics.  It seems the images are some type of PIW format
 
I've seen plenty of document/image formats from Commodore/IBM/Linux/Mac, but have never come across this.  It seems I am not alone.  Neither Microsoft IE nor Google Chrome have any idea how to render such images.  I'll do some research when I get bored if I don't forget, but in the meantime, if anybody can tell me more about the PIW format (and how to view it) that would be great... thanks!

Try using Firefox.  IE is too lame to understand some of these graphics formats, plus it's a security hazard just waiting to get you..

I thought you might bring that up, BDD!  I know you have a preference for pedantatic assemblers that only allow things such as ASL A... (for anyone interested in an in-depth discussion of such things, see this thread).

It isn't a preference for pedantic assemblers.  The problem with assemblers or compilers that are liberal in what they accept is that they are more prone to making interpretation errors and emitting object code that doesn't agree with the source.
 

Anyway, everyone who enjoys tracking down missing/extra spaces in their code: have fun!

As I said, this would not be an issue for a skilled coder.  Missing spaces would produce incorrect output and/or assembly-time diagnostics.  For example, you meant LABEL LDA #<ADDR but instead typed LABELLDA #<ADDR.  How would you expect the assembler to figure out that LABELLDA is supposed to be LABEL LDA?  From the assembler's perspective, LABELLDA is a label.  Your assembler is a computer program, not a mind-reader.   

Tolerance of oddly-positioned whitespace depends on the grammar used in the assembler.  Long ago, I had a copy of an assembler that Fred Bowen was putting together for the C65 (dunno whatever became of the code, but we know what became of the computer).  In it, he was parsing each input line by fields, with some special case testing to account for empty lines, lines that were all whitespace and lines that were comments only.  His code looked for a maximum of four fields, with fields 1, 2 and 3 being the label/symbol, operation (either mnemonic, macro or equates) and operand, respectively.  Anything beyond the third field, regardless of the amount of embedded whitespace, was tossed into the fourth (comment field).  As whitespace was the delimiter between fields, a syntax such as LABEL LDA # <ADDR would have resulted in LDA being assigned to the second field, # to the third and <ADDR to the fourth (comment) field, which would have resulted in an assembler diagnostic.

Academically speaking, Fred's method is correct, in that the third field encompasses everything that is required to generate an operand for the machine instruction.  As machine instructions vary depending on addressing mode and operand size (8 or 16 bits), the addressing mode (#) is part of the operand and syntactically should not be separated from the rest of the operand.  Hence #<ADDR, not # <ADDR, #< ADDR or # < ADDR, is the true operand.

The four field syntax makes sense when you look at the systems to which the assembler was originally targeted.  Processing power and memory space were limited and working with fields, rather than interpreting the input line character by character resulted in faster assembly time.  If whitespace is allowed in fields, then either the field delimiter has to be an altogether different character (e.g., an ASCII <FS>), the field has to be quoted (an opportunity for yet another type of syntax error) or the line parser has to interpret the input a character at a time, maintain state (Was the last character a quote? for example) and make decisions about each whitespace character encountered.  I submit that doing so would make for a much more complicated and error-prone parser, and a slower assembler that is more likely to produce erroneous results when fed source lines with whitespace embedded in operand fields.

On the other hand, "newbsout" is a constant!  When you assemble your program, your compiler...

You mean his assembler will assemble?      Compilers don't assemble.  They translate high level language statements and grammar to assembly code, which is then assembled into machine code.  Terminology can be important, so pardon me for sounding pedantic.

I think the issue is how long an NMI needs to be asserted in order to be recognized.  If you follow MOS Tech "philosophy" then any interrupt source should remain low until cleared (an indefinate amount of time).  On the other hand, MOS Tech documentation states an NMI should remain low for 2 cycles.

I can't speak for the NMOS processors, but I can tell you a 65C02 or 65C816 only requires about 10-60 NS setup time on NMIB in order to respond, and that response occurs about 10ns after the fall of Ø2.

According to the diagram, NMIB is sampled late during Ø2 high.  Processor control setup time is quoted as from 10ns to 60 ns, depending on clock speed (10ns at 14 MHz), and hold time is only 10ns at any clock speed.  Dunno how that equates to the NMOS part, although I am aware that MOS Technology was a bit sloppy with a lot of this stuff.  The CSG timing diagram for the 8502 is really what is needed to settle the matter.

Given what you are trying to accomplish, using CIA #2 makes more sense.  Aside from the Restore key, CIA #2 is the only device in the computer than can generate an NMI.  If you use NMIs to drive your player, you not only get to skip the BRK bit test code at the start of the interrupt handler, you can make some assumptions about the source of the interrupt and thus minimize polling overhead.  That is, if only timer-A in CIA #2 has been configured to generate an NMI, just read CIA #2's ISR to clear the pending interrupt, ignore the flag bits (you already know which one is set) and move on.  You'd only have to test flag bits if you set up another interrupt source.

Incidentally, ganging timer-B to timer-A in itself causes no problems.  The trouble arises if both timers are set up to generate interrupts and happen to hit at about the same time.  Let's suppose timer-A interrupts.  Let's also suppose that by the time the MPU responds to the interrupt and the front end code has been executed, four Ø2 clock cycles remain before timer-B is scheduled to interrupt.  During those final clock cycles, you read the ISR.  That is when the timer-B bug may appear.  So timer-B continues to run but doesn't interrupt, and your program gets all out of whack because of the resulting timing error.

The obvious solution is to never use timer-B as an interrupt source if other sources are configured in the same CIA.  It'll complicate coding but not much you can do about it.

The CIA#1 timer A is used to generate the IRQs.

Are you aware of the timer A IRQ bug present in many 6526s?  Dunno if that would have a bearing on performance, but it might be worth considering.

Quote from: Garth Wilson

Any of the I/O ICs can pull the line low, but the only way it will go up is with a pull-up resistor pulling the line up to the positive power supply voltage. The recommended resistor value is usually 3K. Well, since the IRQ line has some amount of capacitance to ground and other nets, that capacitance multiplied by the pull-up resistor value gives you a time constant. If you put the IRQ-clearing instruction(s) at the end of the ISR, it's possible that there won't be enough time for the resistor to charge that capacitance up to a valid logic-high state before the RTI is done executing. The result will be that as soon as the ISR is done and the old status register flags are restored with the interrupt-disable bit clear once again, the processor is again open to handle another interrupt, so it will respond to the still-low IRQ line because the IRQ has not had enough time to float back up. Remember the rise time with the resistor is much slower than totem-pole-type logic outputs. If you only have one interrupt source on the IRQ line, a 3K pull-up resistor, and only 1MHz clock speed, you can normally get away with clearing the interrupt near the end so you don't need to worry about it; but turn up the clock speed and put more IRQ sources on the line, etc., and you can get into trouble. I mention it because I've been bit by it.

Garth, of course is correct in bringing this up (he, I and others have chewed on this in discussions on the more esoteric aspects of SBC design and layout).  Stray capacitance indeed can cause the IRQ line to be lazy when it is released.  However, this is more a problem with amateur-built equipment, where hand-wired boards are common.  Of course, a sloppy PCB layout can result in the same problem, but that's how we all learn.

When I designed my POC 65C816 SBC (which runs reliably at 12.5 MHz and has been tested to 15 MHz), I was very careful to keep the IRQ paths as short and direct as possible.  In that circuit, there are two possible IRQ sources: a real-time clock that generates a 100 Hz jiffy IRQ, and a dual ACIA (DUART) that interrupts at arbitrary times.  The DUART IRQ is more problematic because each inbound character from the console generates an interrupt, and each outbound character to the console likewise generates an interrupt.  As the console interface runs at 38.4 Kbps, a theoretical maximum interrupt rate of 7,680 per second could occur with CBAT.  In practice, inbound flow is small (I can't type 3,840 characters per second, even after drinking a gallon of coffee), but a complete paint of the screen can generate outbound flow that rate for a short period of time.

Now, if there was a problem with the IRQ line not being able to quickly change state, it would have already been apparent.  This is because early in the testing phase of the design I set up a loop-back on the second serial port and had it run CBAT at 38.4 Kbps for several days.  Therefore it was hammering the MPU with IRQs all the while I was fooling around on the console, which is wired into the first serial port.  To make sure that the CBAT loop was running error free I had the MPU maintain two 32 bit counters, one counting the number of characters transmitted and the other the number received intact.  Now, at 38.4 Kbps, 27,648,000 chars are sent per hour, or 663,552,000 per day.  I stopped testing after three days, when it became clear that the error rate was zero.

In examining the PCB from my C-128D, it is patent that Commodore went through a fair amount of effort to keep the IRQ path reasonably short.  While an IRQ rate much over 10,000 per second is unlikely in a 128 (or practical—the MPU would have little time to do anything except service interrupts), I don't see any reason why that rate wouldn't be supported by the hardware.  So if errors related to interrupt processing, or the ignoring of IRQ when SEI has been executed, were to occur they would point to an internal problem in the 8502 itself.  The problem with pointing the finger at the 8502 is that, given the number of 128s that were in use, if this problem did truly exist it would have been stumbled over many times.  I'm reasonably certain that I would have run into it with all the coding I did on the 128.

The specifications for the entire 65xx family states that when

• IRQ[/o] is asserted the current instruction is completed and then the interrupt disable bit in the status register is tested to see if the IRQ should be acknowledged.  Examining the timing diagram shows that while
• IRQ[/o] is an asynchronous signal, the MPU only samples at it late in the Ø2 high part of the last machine cycle of the current instruction.  By then the current instruction has been executed and the address and data buses have been made valid.  Since the next opcode fetch will not occur until the following Ø2 high, the MPU has one-half of the Ø2 cycle to decide whether to process or ignore the interrupt.  On an 8502 running at 2 MHz, that amounts to 250 nanoseconds.
  
  In the context of SEI, by the time the MPU samples
• IRQ[/o] the I bit is already set in the status register.  Therefore, any interrupt during the two machine cycles required to execute SEI should not be acknowledged and [/size][/font]at no time should the MPU ever spuriously process an IRQ in the Ø2 cycle following the SEI instruction.  It's certainly possible, of course, that errata exists in the MPU that would cause an IRQ to be processed immediately after SEI, but that's a hardware defect with that particular MPU.
  
  The fact is that countless millions of 65xx MPU have been (still are) in use, many in real-time embedded systems that are entirely interrupt-driven.  If this problem was systemic to the MPU design, a lot of people would already know it and it would be common knowledge.

Quote from: BigDumbDinosaur on April 22, 2011, 08:14 AM

Is this product still around?

     You have the contact information for Jeff of MyTec Electronics, as do I.  So do you want to contact him first or should I?

          Back in California,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 23-24 Commodore Vegas Expo 2011 - http://www.portcommodore.com/commvex

You contact him.