GARTHWILSON wrote:
Replying to lots of things on this page (13), without quoting:
We used BRK to get back to the monitor on the AIM-65's we used in the 6502 class in 1982. Five years later in a work project, I did the other functions talked about with JSR BREAK, and BREAK let me see the address, the contents of all the registers, peek around, modify things, etc., and then pick back up at the instruction following the JSR BREAK. Not using BRK made the ISR faster, not having to check the B bit.
BRK is only used in systems' software, and this would be written within the context of the multi-tasking OS on the 65VM02. I think BRK can be discarded.
I used BRK in my debugger, and it really bloated out the code a lot. If I had used JSR BREAK instead, the bloat would have been considerably worse. So this is an argument for BRK. This argument only makes sense in regard to an STC (subroutine-threaded code) Forth system. In a byte-code VM you would just have a primitive BREAK that the compiler compiles as needed. The whole idea of the 65VM02 is to run a VM (hence the name), so I don't anticipate anybody generating machine-code --- or, at least, if they do, then this would be pretty minimal, such as an optimizing compiler that generates new primitives on the fly --- if they want a single-step debugger (C programmer's usually do) then they won't be doing BRK inside of primitives, but they will just use a BREAK primitive as described above.
So, BRK can be discarded. Everything else in the 65c02 will be kept for compatibility however.
GARTHWILSON wrote:
In Forth, (ZP,X) is used to point to memory locations whose addresses are on the data stack, since the programmer won't know ahead of time where the top of the stack will be when the particular code is run. Storing, retrieving, or RMW instructions to locations whose addresses are on the data stack are all game. X is the stack pointer.
In my current design, I am assuming that a split-stack is used. This means that you have one stack for low bytes and one stack for high bytes, both indexed by X (I got this idea from ISYS Forth on the Apple-IIc that my cross-compiler was compatible with). The advantage here is that only one INX is needed to drop a 16-bit value from the data-stack, and one DEX to make room for a new 16-bit value.
I'm thinking now however, that I might change this and go with a combined stack in which the low and high byte are juxtaposed. This would involve adding these instructions:
Code:
DINX add 2 to X effectively the same as: INX INX
DDEX subtract 2 from X effectively the same as: DEX DEX
LDYA direct load YA from the direct-page variable
LDYA (direct,X) load YA indirectly from an array of direct-page pointers indexed by X
STYA direct store YA to the direct-page variable
STYA (direct,X) store YA indirectly to an array of direct-page pointers indexed by X
This would actually be a lot more efficient. I was looking at my code and I was not happy with having to do this at the front of almost every primitive:
Code:
LDY toslo,X
LDA toshi,X
I'm pretty dubious of adding PHM and PLM as I mentioned previously. I can't think of any use for these other than ENTER and LEAVE --- nobody has mentioned any use that they know of.
A better idea is to introduce a new register called F that holds the local-frame pointer, rather than use the LF direct-page pointer. This involves adding a raft of new instructions though, which complicates the processor a lot. Whether this is worthwhile or not, depends upon how much local variables are used. In Forth, a lot of functions don't have local variables at all, but only use the data-stack. In C, Pascal, etc., the functions only use local variables and don't have a data-stack, so the F register would be hugely helpful to speeding up these languages.
I will give some further thought to these matters and come up with a new version of the document pretty soon.
GARTHWILSON wrote:
The cars I've seen the fuel injection on used one sprayer for all the cylinders, and it sprayed continually. The computer told it how heavily to spray; but it did not turn off between intake strokes. I can imagine a reason to have a sprayer for each cylinder, but I think you'd want to have it far enough upstream to give the fuel more time to evaporate, and you wouldn't want the intake air to be "striped."
Well, fuel injection means you have a "sprayer" for every cylinder. Ye olde carburetor was a sprayer for all the cylinders.
I think Garth is correct though, that the only accurate timing that needs to be done is of the ignition. You can't actually turn a sprayer on and off rapidly due to physical limitations of valves, which are large mechanical contraptions.
I admit that I'm not an auto mechanic though.
My previous calculation of how many ignitions you have was totally screwed up. I figured it out though:
Code:
M = maximum revolutions per minute
C = cylinders
T = time in microseconds between ignitions
T= 1E6 / (M/60)*(C/2)
So, for an 8 cylinder engine at 6000 rpm, we have 2,500 microseconds, or 2.5 milliseconds.
This is pretty pedestrian. A 25 Mhz. 65VM02 is far more than fast enough for this.
The 2 Mhz. 65c02 is plenty fast enough for this. The reason a 65c02 isn't a realistic choice, is because it only has IRQ and NMI and hence each ISR has to poll the I/O to figure out what tripped the interrupt. Modern processors, including the 65VM02, have a lot of interrupts though.
I still don't know why a PowerPC/eTPU is needed --- that is a hugely powerful computer (significantly more powerful than the desktop computers of the early 1990s) --- maybe car manufacturers are just a conservative lot who feel more comfortable with a big powerful computer so there is no danger whatsoever of lacking enough computer power to do everything that anybody may ever think of needing.
As I said before, maybe the 65VM02 would be used by Yugo for their next cheapo gas-guzzler that is unsafe at any speed --- they actually used cardboard for the interior paneling --- within that context, they might consider the 65VM02 to be right up their alley!
As for NASA, they might consider the 65VM02 also --- I would expect it to use less power than the RTX2010 that they currently use --- but I don't care if NASA uses it or not, because there is no money is supporting onesy/twosy projects.