This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - BigDumbDinosaur
Pages:  2 3 ... 27 Next
« on: December 09, 2012, 09:34 AM »
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.
« on: October 10, 2011, 03:12 AM »
The "SID Symphony II" cartridge is now available, and can be found on the Digital Audio Concepts website (http://digitalaudioconcepts.com), along with the internal stereo SID board and my prototyping cartridge board.
« on: September 25, 2011, 12:05 PM »
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.
« on: September 25, 2011, 11:55 AM »
When I read the manual using DIR command is confusing.
I can display directory of HDD, but not 1581/1541-II.
In description of DIR command is written only about LU (Logical Unit)...
RA DOS commands, such as DIR, AUTOCOPY, etc., only affect the RA unit.
« on: July 21, 2011, 12:34 AM »
Where is possible to get Rear Admiral DOS & HDD?That I don't know.
« on: July 16, 2011, 07:36 AM »
Get a Rear Admiral hard drive system and use the disk like virtual RAM. It's as fast, and no hardware hacks are needed.
« on: July 13, 2011, 02:34 AM »
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.
« on: July 10, 2011, 01:04 PM »
Does anyone have a copy of LADS for the C-128? It is a assembler/disassembler for the C-128.
I've never heard of LADS. The only C-128 native mode assemblers with which I am familiar are Dev-Pak and Buddy. There were one or two others, but those are the two that I used back in the day.
« on: June 25, 2011, 07:20 AM »
Good thing your boss didn't leave a few zeroes off your paycheck!
Bugger - my mistake, was fiddling with the settings and accidently left some 0's off it
« on: June 13, 2011, 01:56 PM »
Duh do not know is it posted some where lol
Not anymore it isn't. <Grin>
« on: June 01, 2011, 01:18 AM »
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..
« on: May 27, 2011, 12:56 AM »
I've changed the forum setup to allow unlimited attachments per post and unlimited size of attachments.Unlimited until the disk space runs out. Okay if I store image copies of my office file and print server?
« on: May 22, 2011, 03:25 AM »
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: May 20, 2011, 10:46 AM »
I added the space for clarity. I suggest better software if the source doesn't assemble because of a space in an expression.Assuming the assembler obeys the four field MOS Technology syntactical standards for 6502 assembly language, # < would not be accepted as correct. As the assembler parses the code lines looking for unquoted whitespace, the # would be interpreted as a field, and <... as another. I tried it on the three assemblers I have here (one of which is the WDC "official" assembler). Only one assembled a line with # < before the address. On examination of the object code, it was wrong—the # had evidently been ignored, as the binary equivalent of LDA <ADDR had been assembled, not LDA # <ADDR.
Few things are more frustrating than tracking down a missing / extra space.A disciplined programmer wouldn't have such an issue, as s/he would have developed good coding habits.
« on: May 19, 2011, 10:23 AM »
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.
« on: May 19, 2011, 10:18 AM »
Ahem. No space between # and < or >. Also, the code should be:
lda # >newbsout
lda # <newbsout
« on: May 19, 2011, 10:09 AM »
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.
« on: May 18, 2011, 11:30 AM »
For the lost NMI, that is of interest, but not strictly a bug, if the spec tells us to keep NMI asserted for some length of time? And in normal practice, NMI would be asserted until serviced, I think. Or am I confusing with IRQ?As NMI is edge-sensitive, multiple NMIs are not possible. It's not a "bug," it's a "feature."
« on: May 14, 2011, 01:44 AM »
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.
« on: May 13, 2011, 03:10 AM »
BDD, is there some specific bug that C128 programmers should be aware of? I've heard about the TOD/Alarm bug... but you have something else in mind?I incorrectly referred to the problem as the timer-A bug—it actually affects timer-B. The specific problem is if the interrupt status register (ISR) is read one or two Ø2 cycles before a timer-B interrupt is scheduled to occur, the relevant bit in the ISR will not be set and the interrupt will not occur. Not all 6526s will exhibit this problem. However, George Hug, a contributor to Transactor, noted that most 6526s displayed this problem, and was one of the reason why higher baud rates failed in the fake RS-232 routines in both the C-64 and C-128. As far as I know, no such problem exists with timer-A.
Considering your work on [your] dual port serial adapter, I thought you might have some suggestions / preferences to using IRQ versus NMI. As I understand your adapter runs about 38k (bits)which is about 4.75k byte/s...Actually, it's 3.8 Kbps, since in addition to the eight data bits, there is a start and stop bit—10 bits total per byte transferred. One interrupt is generated per byte transferred, so the IRQ rate is equal to the Kbps/10.
...and comparable to the 7.8kHz (bytes/s) interrupt rate I'm using. So maybe you know some effecient techniques for managing that data flow ? I also understand it uses an ACIA not a CIA, but I would think there's some similarities in programming...The 8502's interrupt latency is the same for both IRQs and NMIs. Depending on the instruction currently being executed, up to seven Ø2 cycles may elapse before a hardware interrupt is acknowledged. Although the MPU must test the I bit in the status register upon detection of an IRQ, the published specs don't indicate any difference in performance between the two interrupt types.
On the C-128, some interrupt processing overhead is present in the vectored code near the top of the kernel ROM and is executed before the jump is taken through the page three indirect vectors. You can't avoid this overhead but you can arrange for your interrupt handler to be the immediate target of the indirect vector so your handler has highest priority. If you determine that the IRQ is yours (i.e., timer-A underflow), finish your IRQ code by going directly to the CRTI common return at $FF33 in the kernel ROM, or duplicate that code in your handler to avoid the extra clock cycles of the jump to CRTI.
One thing that could be a performance factor is the processing of the IRQ routines in the BASIC interpreter. Those routines are responsible for moving sprites, playing music and similar such periodic activity, and with each jiffy IRQ. If you are not using any of these features you can tell the IRQ subsystem to skip them by clearing bit zero of the INIT_STATUS flag at $00A04. This should reduce some of the processing overhead.
Something else to look at is the structure of your interrupt handler. You want to use as much linear code as possible. Each JSR will cost you six clock cycles plus the six cycles required by RTS. Look carefully at relative branches as well. Try to arrange your code so jumping and branching occurs only for the least common case. Also recall that a branch across a page boundary uses an extra clock cycle to compute the MSB of the branch target's address. If possible, use the stack for temporary storage. PHA-PLA uses one less clock cycle than STA ADDR-LDA ADDR, as well as less memory.
If you are using data tables and indexed addressing to access them, see if you can page-align the tables to avoid a cross-page indexing penalty. Place the most often used data near the start of the table. Speaking of data tables, where possible use them in place of run-time computed values. Fewer instructions will have to be executed, ergo fewer clock cycles.
The basic problem you are up against is the relatively slow clock rate of the C-128, even in FAST mode. The IRQ rate you are using means much of the 8502's time is being consumed in servicing IRQs. Potentially, 21 clock cycles will be consumed per IRQ in MPU internal overhead—before your IRQ handler actually gets anything done. This breaks down to seven clocks to account for interrupt latency, seven clocks in front end overhead (pushing the PC and SR to the stack, and loading the PC with the IRQ vector) and seven more executing RTI, which reverses the stack pushes performed when the IRQ was initially processed. Multiply that by your interrupt rate (7800) and you are consuming up to 163,800 clocks per second in MPU overhead—and that's before you actually do any useful work. In other words, 8.2 percent of the clock cycles available in one second is potentially consumed in internal MPU overhead.
To put that into perspective, the fastest MPU instructions require two clock cycles and, on average, you will consume four to five clock cycles with the most commonly used instructions. Let's assume four for now. At 2 MHz, you can theoretically execute 500,000 instructions per second, assuming no interrupts of any kind. Now, let's subtract the MPU's internal IRQ processing overhead. At an interrupt rate of 7800 per second, that leaves you with 459,050 instructions that can be executed per second, both for interrupt and foreground processing. We haven't accounted for the initial kernel code executed at each interrupt (register pushes, changes to the MMU, testing the BRK bit, etc.), the code executed to pull registers and restore the memory map at the end of the interrupt handler, or the additional load of the 60 Hz jiffy IRQ, which potentially eats up another 1260 cycles each second in MPU internal overhead, as well as in executing the front and back end IRQ handler code. I think you can see where the conversation is headed.
Since your code is timing-critical, you need to go through it top to bottom to weed out as much inefficiency as possible. I think the 7800 IRQ rate is sustainable, but not unless your IRQ handler is very tight.
*Conclusion*Based on my experience with the Lt. Kernal and direct access methods, it would easily sustain the required data rate. Even back when it was using ST-412 drive mechanisms, it was possible to load a 512 byte block into RAM in about 30 milliseconds, worst case, an effective data transfer rate of 17K per second. On average, transfer rates were much higher, sometimes approaching 65K per second. The CMD drive was never able to reach that transfer rate.
Now videos are playing very well on my SD2IEC device. Not so well on C1581 because of stupid Commodore and/or JiffyDOS ROMs. I wonder how a CMD-HD would hold out? Anyway, one way to fix the problem is to burn a custom ROM without stupidity built into the transfer routines.
I'm still open to other options...
« on: May 09, 2011, 01:56 AM »
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.
« on: April 30, 2011, 12:08 AM »
Hello!Welcome aboard! I surprised you don't have a B-128 to go with the rest of your "stable."
This is my first post here. I've own Commodore Computers from 1984/5 C-16 was my first, C-128 and Amigas ... I came from amiga.org now I'm starting to revive my forgotten 8 bit computers. Actually I've got: A500(4),A500+ HD (2), A600HD, A1200HD 030 A1200 HD 020, A2000HD, A2000HD 030 ECS, A3000, A4000 060, CDTV and C64 (2), C16 (2), Plus4 (2), C128 Flat (2) - 1541-1541II-1551-1571.
best regards from Spain
In my opinion, Commodore signed their own death warrant when they got started with the Amiga. A huge investment with a miniscule payoff.
« on: April 27, 2011, 02:57 PM »
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.
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.
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.
« on: April 25, 2011, 12:47 AM »
I've never heard of or run into such a problem. Many a times I've coded something like the following without any execution problem:
ldx #<myirq ;new IRQ handler
sei ;interrupts off
stx cinv ;set new IRQ vector
cli ;interrupts on
and not had a crash due to the interrupt vector LSB being changed on the next instruction after SEI. Surely something untoward would have happened if the MPU's reaction to the SEI instruction wasn't immediate. It could be your particular 8502 does have a problem. Only way to find out for sure is to try it out on another real C-128.
« on: April 25, 2011, 12:35 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,
Fresno Commodore User Group
July 23-24 Commodore Vegas Expo 2011 - http://www.portcommodore.com/commvex
You contact him.
Pages:  2 3 ... 27 Next