From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2008-09-05 15:55:33
Hello Ruud et al.,
* On Fri, Sep 05, 2008 at 11:51:36AM +0200 ruud.baltissen@apg.nl wrote:
> Yesterdays conclusions were based on tests in VICE at work
... snipp ...
Don't take VICE too serious here.
The FDC is not emulated by emulating the 6502 and running the code of
the FDC; instead, it is emulated "on a high level" only (cf.
src/drive/ieee/fdc.c, function int_fdc()). There are even remarks in the
code that clearly state the person who has written that was not sure
about the details. Thus, my previous analysis might be specific to VICE
only.
Now, it is really this problem with the FDC which prevents the code from
working on VICE. Do as follows to prove this:
Start xpet, select drive 8 as 8250, and enter your program into xpet:
100 open1,8,15
200 for i=0 to 15 : print i;
210 print#1,"m-w" chr$(i) chr$(18) chr$(1) chr$(i)
230 next
240 print : print
400 for i=0 to 15
410 print#1,"m-r" chr$(i) chr$(18)
420 get#1,a$ : if a$="" then a$=chr$(0)
430 print asc(a$);" "; : next
Go to the xpet monitor (Alt+M on Windows) and enter:
break d328
x
Now, run your program by entering "run" and pressing enter.
Whenever xpet enters into the monitor, enter the following two lines:
r PC=d32b
x
Thus, jumping over the JSR $FAA7 at $D328 (of course, you could also NOP
it; however, I am not sure where you would have to fix the checksum
routine of the 8250 for the RESET.)
You will see that your program works as expected.
Note that you need exactly the same procedure for the "M-E" command.
Thus, I would expect this problem to be a deficiency of the VICE 8250
emulation, not a problem of the 8250 itself. However, currently, I am
not sure about this.
Also note that this problem with resetting killp_flag only affects the
following places of the 8250 ROM:
- $D328 (all M-x commands other than M-R)
- $D5B1 (the B-E command)
- $F1E2 (although named "boot4", this seems not to be called via RESET
or so; I don't have a clue what this is. Is there a "boot"
command for the 8250? Is it the "&" command?)
It seems that the 8250 main CPU ("BC") waits for the IRQ of the other
CPU ("FDC") to take place and end before executing these commands. To
me, this seems to be some "poor man's" (and ineffective?)
synchronisation between both CPUs. The BC wants to make sure that while
performing the operation, the FDC will not interrupt in that instance of
time.
Thus, taking all into consideration, it is very likely that such a
deficiency will not be noticed for long time in VICE/xpet.
I tried a quick'n'dirty fix for VICE for this problem.
http://www.trikaliotis.net/Download/vice-8250-fix.diff.gz
and the corresponding compiled xpet program:
http://www.trikaliotis.net/Download/xpet-8250-fix.zip
Note: This is really a quick'n'dirty hack. It fixes this issue for the
8250, but it might introduce other problems, especially for other
drives! I do not yet understand all the implications of this patch ,
either, nor did I have a look at the FDCs of the other IEEE drives if
they behave the same or not. I did not check if these two extra lines
are added at the right place of the int_fdc() routine. Thus: Use at
your own risk!
And, Ruud: If you do not answer again, I will not answer to any of your
statements/questions anymore now and in the future. ;)
Regards,
Spiro.
"Anybody who would spend considerable effort emulating a C64 is not
particularly sane to begin with; it is unreasonable to expect them to produce
sane software."
("asuffield" in http://forums.thedailywtf.com/forums/p/7199/134136.aspx)
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.