Jump to content

Photo

DSR error 0094 when I try to use COPY directive in E/A II


77 replies to this topic

#51 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 3, 2019 8:54 PM

Ok but I still think you pulled 1% out of your butt.

Nope, that came directly out of my stopwatch.

Look, don't take my word for it, I'm wrong lots of times. Try it for yourself. Pick a big XB program of your choice and try running it with 32K on the 8 bit bus and then on the 16 bit bus. If your TI setup doesn't allow this you can use Win994a which lets you choose between those options. Post your results here.  If you can find a program that runs even 5% faster I will buy you the biggest steak on the menu at Uncle Louie's Steakhouse in Cortland.

 

I should add that we're talking about XB only here. Assembly subroutines will benefit noticeably from the faster memory.


Edited by senior_falcon, Thu Jan 3, 2019 9:19 PM.

  • RXB likes this

#52 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 3, 2019 9:58 PM

I was having trouble finding a program to test, but then remembered a disassembler that I wrote a long time ago. This is written in straight XB with no assembly subroutines. (Don't laugh at how slow this is!)

To disassemble ram from 7000 to 7080 it took 153 seconds on the 8 bit bus and 152 seconds on the 16 bit bus. That works out to be a whopping .66% faster from running on the 16 bit bus. I think my steak is safe.

 

The most tedious part of 256DEMO took 135 seconds on the 8 bit bus and 119 seconds on the 16 bit bus. That is about 12% faster. This is about what I would expect, because the XB program spends much of its time time running assembly subroutines and these do benefit from being on the 16 bit bus.



#53 RXB OFFLINE  

RXB

    River Patroller

  • 3,457 posts
  • Location:Vancouver, Washington, USA

Posted Sat Jan 5, 2019 5:40 PM

I was having trouble finding a program to test, but then remembered a disassembler that I wrote a long time ago. This is written in straight XB with no assembly subroutines. (Don't laugh at how slow this is!)

To disassemble ram from 7000 to 7080 it took 153 seconds on the 8 bit bus and 152 seconds on the 16 bit bus. That works out to be a whopping .66% faster from running on the 16 bit bus. I think my steak is safe.

 

The most tedious part of 256DEMO took 135 seconds on the 8 bit bus and 119 seconds on the 16 bit bus. That is about 12% faster. This is about what I would expect, because the XB program spends much of its time time running assembly subroutines and these do benefit from being on the 16 bit bus.

Just wondering this program used CALL PEEK?

 

If the disassembly was of RAM in the 32K instead of the XB ROM it would have been much faster as the ROM is on the 8 bit bus thus your test gave a bonus to 8 bit bus.

Thus ignored the faster RAM on purpose. Nothing like testing a difference and giving the advantage to the default slower one in that test, which is what this test did.

 

A real answer would have been to do a comparison using the faster RAM vs the slower RAM which is not what you did.

Used as little advantage as possible for the faster RAM and as much advantage as possible for slower RAM.



#54 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 38 posts

Posted Sat Jan 5, 2019 6:14 PM

"Like I said I am very sure you ran dinky program tests so everything you did still 100% ran from only VDP in both XB and TI Basic, thus your belief is based on faulty tests."

You may be "very sure", but the fact of the matter is that I ran large programs as well. And by the way, this was testing the speed differences running the same program in XB using no 32K, using 32K on the 8 bit bus, and using 32K on the 16 bit bus. Virtually no difference in speed

I am thinking that there would be a much larger difference between XB with no 32K and XB with either of the 32K RAM models, than there would be between the 8 bit 32K and the 16 bit 32K.  In fact, without disabling some of the wait states I would expect to find no difference between the 8 bit and 16 bit benchmarks.  I believe this is because the 32K is located in the >2000 - >3FFF and >A000 - >FFFF memory space.  These addresses are always wait stated unless there is a hardware override.  From what I've read so far it would seem to be inadvisable to try to override the wait states when running the TI RAM in the PEB, or the daisy chain memory from TI.  Both are totally dependent on the extra time provided by the wait state generator for reading.  Writing to them is not so problematic, if I remember correctly.

 

I'm surprised the performance penalty for using VDP memory for XB doesn't make more of a difference.  I guess that just means the performance penalty for using the slow RAM is quite substantial as well.

 

Many years ago I installed 32K on the 16 bit bus which has no wait states, plus a switch so I could restore the wait states if needed. As you would guess, there is a noticeable improvement in speed. An assembly program running totally on slow ram including the workspace would run in about 60% of the time when running on the fast RAM. Not twice as fast, but a nice speed increase. Of course in the real world, most assembly programs already put the workspace in the fast scratchpad ram. With the workspace already on fast ram, putting the program into fast ram does not lead to such a dramatic increase. It might run in around 75% of the time. Not earth shattering, but still a decent speed increase.

Do you know how many, and which of the wait states were disabled during these tests? 

 

HH



#55 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Sat Jan 5, 2019 8:46 PM

Just wondering this program used CALL PEEK?

 

If the disassembly was of RAM in the 32K instead of the XB ROM it would have been much faster as the ROM is on the 8 bit bus thus your test gave a bonus to 8 bit bus.

Thus ignored the faster RAM on purpose. Nothing like testing a difference and giving the advantage to the default slower one in that test, which is what this test did.

 

A real answer would have been to do a comparison using the faster RAM vs the slower RAM which is not what you did.

Used as little advantage as possible for the faster RAM and as much advantage as possible for slower RAM.

Rich, you just want to argue. My reason for disassembling the XB roms is because they are there and that way I didn't have to load anything.  If I were to disassemble something in fast memory, it is true that there would be a bit of a speed increase - it might even be as much as .7% faster instead of .66%. If I were to disassemble code on the fast RAM you would just find something else to complain about.

 

You have yet to post ANY XB program that demonstrates a significant increase in speed when running straight XB (with no assembly subroutines) on the 16 bit bus. The reason for that is simple - there are none.

 

Ambrose Bierce comes to mind:

“Positive, adj.: Mistaken at the top of one's voice.” 

― Ambrose Bierce, The Unabridged Devil's Dictionary

Edited by senior_falcon, Sat Jan 5, 2019 9:24 PM.


#56 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Sat Jan 5, 2019 9:11 PM

I am thinking that there would be a much larger difference between XB with no 32K and XB with either of the 32K RAM models, than there would be between the 8 bit 32K and the 16 bit 32K.  In fact, without disabling some of the wait states I would expect to find no difference between the 8 bit and 16 bit benchmarks.  I believe this is because the 32K is located in the >2000 - >3FFF and >A000 - >FFFF memory space.  These addresses are always wait stated unless there is a hardware override.  From what I've read so far it would seem to be inadvisable to try to override the wait states when running the TI RAM in the PEB, or the daisy chain memory from TI.  Both are totally dependent on the extra time provided by the wait state generator for reading.  Writing to them is not so problematic, if I remember correctly.

 

I'm surprised the performance penalty for using VDP memory for XB doesn't make more of a difference.  I guess that just means the performance penalty for using the slow RAM is quite substantial as well.

 

Do you know how many, and which of the wait states were disabled during these tests? 

 

HH

The 32K in my TI is piggybacked on top of the ram console rom chips. for the scratchpad memory. There is no 32K in the expansion box. My understanding is that there are no wait states. In any case, the memory is accessed at the same speed as the scratchpad memory and console ROMs.

 

The reason there is so little difference when running in VDP ram, or slow or fast cpu ram is simple. XB reads instructions or data from ram and then spends a LOT of assembly or GPL instructions processing that data. The amount of time spent accessing the ram is trivial compared to the time it takes to process it. You can prove this to yourself with Win99/4a which lets you turn off the 32K memory so you are forced to run in VDP ram; then you can turn on 32K and try it on both the 8 bit bus with the wait states or the 16 bit bus without wait states. The difference in speed is trivial - maybe 1%.

 

I should add that a very large program running in VDP ram might be noticeably slower if there were a lot of string manipulation. The reduced stack space would lead to more frequent "garbage collections" which would probably slow it down some. I don't know how much this would effect the speed. I do know it wouldn't be faster!

 

If you could find a way to have the XB ROMS in fast ram you should notice a speed increase. I don't know whether that is possible. On the other hand, programs running in assembly are noticeably faster.


Edited by senior_falcon, Sat Jan 5, 2019 9:34 PM.


#57 RXB OFFLINE  

RXB

    River Patroller

  • 3,457 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jan 6, 2019 5:09 AM

Everything in TI Basic runs from VDP. Thus Garbage Collection occurs at insane number of times.

 

XB has 12K of String Space and temporary variables thus results in way less number of Garbage Collection times.

 

The biggest problem with both is every number is Floating Point even For A=10 to 20 is converted from FP to Integer every increase of 1

 

Assembly does not suffer from this huge disadvantage. Thus even counting from 1 to 10 is a huge disadvantage for XB or TI Basic.



#58 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Sun Jan 6, 2019 9:48 AM

Rich, you have to focus...  What you say about TI BASIC is true, but we are talking about comparing Extended BASIC running with 3 different memory options. As you may already know, when there is no 32K expansion then the entire XB program plus variables and strings are contained in VDP memory. This leads to more frequent garbage collections as noted in my post #56.

 

I realized just how sneaky and devious I was in trying to slip a faulty test past your watchful eyes in my post #52. You stated, "If the disassembly was of RAM in the 32K instead of the XB ROM it would have been much faster." I'm not sure my aging reflexes are fast enough to detect the difference, so let's calculate it. Disassembling from  >7000 to >7080 involved >80 CALL PEEKs. That is 128 accesses to slow ram that could have been to fast memory instead.  Lets say each of those accesses took an additional 24 clock cycles. (I think this is too high by a factor of about 2 but I don't want you accusing me of intentionally slanting the results.) That would be about 3000 additional clock cycles. Since the TI runs at 3MHz that would be 1 millisecond faster. So the program would have run in 151.999 seconds instead of 152. You can see how my geriatric fingers on the stopwatch might have trouble detecting such an increase.


Edited by senior_falcon, Sun Jan 6, 2019 9:53 AM.


#59 RXB OFFLINE  

RXB

    River Patroller

  • 3,457 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jan 6, 2019 5:18 PM

Hand Stop watch to time a computer.

 

Put it on the Internet and see the response....



#60 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Sun Jan 6, 2019 6:26 PM

Hand Stop watch to time a computer.

 

Put it on the Internet and see the response....

????????

 

I notice that you haven't posted any XB programs that show a speed increase when on the 16 bit bus. There are two possibilities:

You haven't been able to find one. 

You have been too busy posting to have time to look.

Both are strong possibilities.



#61 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 38 posts

Posted Mon Jan 7, 2019 11:08 AM

The reason there is so little difference when running in VDP ram, or slow or fast cpu ram is simple. XB reads instructions or data from ram and then spends a LOT of assembly or GPL instructions processing that data. The amount of time spent accessing the ram is trivial compared to the time it takes to process it. You can prove this to yourself with Win99/4a which lets you turn off the 32K memory so you are forced to run in VDP ram; then you can turn on 32K and try it on both the 8 bit bus with the wait states or the 16 bit bus without wait states. The difference in speed is trivial - maybe 1%.

I can believe there is a LOT of processing going on to process any BASIC language.  I can further believe there is even more processing going on in interpreting BASIC and XB on the TI99, because it is an interpreter interpreting an interpreter that uses mostly VRAM.  What I can't accept is that a test performed on any TI99 simulation would be valid test of the real thing's actual performance. :)  For the most part I have found that the real computer is slower than the emulation.  Emulators are always full of shortcuts around hardware that the author doesn't understand, or finds too difficult to simulate.  The DSR in the TI99 disk drive comes to mind.  Besides, I don't run Windows on my main machine.  I run Linux.

 

I am considering a couple of schemes for eliminating wait states on one of my TI99s.  The two front runners are Thierry Nouspikel's and an alternative scheme of my own.  I intend to do both of them, but I'd like to look at what others have done.  And so I would like to learn more about the method used in your computer.  I'd appreciate it if you could answer a few questions about it.

 

1) What problems, if any, do you have with any of the hardware when you have it in the no wait state mode?

2) What is the wait switch attached to?

3) Do you have some instructions that you followed to install it that you could send to me?  And maybe a picture of the finished project?

 

Regards,

HH



#62 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Mon Jan 7, 2019 12:24 PM

http://www.mainbyte....32kconsole.html

 

I think this is what I did.

 

Regarding speed, I think Win994a is pretty close and it is easy to chose the fast memory, slow memory or no memory. It is true that disk access time is usually way faster, so a speed test that involves disk access will be too fast on an emulator.

 

This is not to slight Classic99, which I also think is pretty accurate for speed. (And which for me is much better for development work .)

 

(edit) I also use Linux. I run Windows XP in Oracle's Virtual Box and do all my TI development work there.

As far as any hardware problems with the faster memory - I don't remember any. The only problem I remember is that the Tennis game did not like the faster speed. The players would split and there would be legs walking around with the head and torso displaced to the side.


Edited by senior_falcon, Mon Jan 7, 2019 1:55 PM.


#63 RXB OFFLINE  

RXB

    River Patroller

  • 3,457 posts
  • Location:Vancouver, Washington, USA

Posted Mon Jan 7, 2019 3:31 PM

????????

 

I notice that you haven't posted any XB programs that show a speed increase when on the 16 bit bus. There are two possibilities:

You haven't been able to find one. 

You have been too busy posting to have time to look.

Both are strong possibilities.

Very true, I do not have hard ware skills to put 32K on 16 bit bus in a TI99/4A and that is required.



#64 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Mon Jan 7, 2019 4:18 PM

Very true, I do not have hard ware skills to put 32K on 16 bit bus in a TI99/4A and that is required.

Win994a will do the trick for you. Simple and easy to use. This runs on Windows which I think you use.



#65 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Mon Jan 7, 2019 8:31 PM

What I can't accept is that a test performed on any TI99 simulation would be valid test of the real thing's actual performance. :)  For the most part I have found that the real computer is slower than the emulation. 

HH

 I compared the real TI99 with both Win994a and Classic99, running the same program simultaneously on both.

10 FOR I=1 TO 1000::PRINT SQR(I)::NEXT I

Interestingly enough, both emulators were a bit slower than the real TI. Win994a was the closest at about 3.5% slower. Classic99 was about 7.3% slower. 

I run these in XB running in Linux using Oracle Virtual box and perhaps that is the reason they are slower. There is no substitute for the real thing, but I do think that Win994a does a good job implementing the slow/fast memory option and is useful for comparing the speed of the same program with various memory options.


Edited by senior_falcon, Mon Jan 7, 2019 8:31 PM.


#66 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,420 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 8, 2019 12:48 AM

Interestingly enough, both emulators were a bit slower than the real TI. Win994a was the closest at about 3.5% slower. Classic99 was about 7.3% slower.


Is your Classic99 up to date? (399.004). The last few releases saw some timing tweaks... I use it to verify performance of video playback now, and I don't see much difference to the TI next to me.

#67 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Tue Jan 8, 2019 7:06 AM

Nope, it i

 

Is your Classic99 up to date? (399.004). The last few releases saw some timing tweaks... I use it to verify performance of video playback now, and I don't see much difference to the TI next to me.

Nope, it is 398. I will update and try it tonight.



#68 hhos OFFLINE  

hhos

    Space Invader

  • Topic Starter
  • 38 posts

Posted Tue Jan 8, 2019 7:28 AM

http://www.mainbyte....32kconsole.html

 

I think this is what I did.

WOW!  That was quite a project.  That's going to take some time to figure out.  I too am planning on piggy-backing onto those ROM chips, but I'm putting RAM chips to replace the ROMs.  The RAM will act as ROM chips until I'm ready to change something.  There will be battery backup with appropriate steering diodes to keep them from blanking out at power off.  The ROMs will stay so I can  go running home if I get into trouble, but I will have 64K of pseudo ROM to work with.  I think I am still planning on replacing the console RAMs with my two 32K RAMs.  That way they are set, with a couple more address lines, to fully populate the 1K console RAM space.  Then I will add the necessary decoding for the rest of the RAM.  That reminds me.  I still haven't checked the pin alignments for the 6810 chips!  Yikes!  Bad idea, bad idea!  I guess those are from an era before they started to standardize the SRAM/EPROM pinouts.

 

Your mod has 64K RAM and only 32K is used?  Did they put some of the extra memory into that space, or do you still only have 256 bytes in the >8000 to >83FF address area?

 

 

 There is no substitute for the real thing, but I do think that Win994a does a good job implementing the slow/fast memory option and is useful for comparing the speed of the same program with various memory options.

I don't say that emulators are useless for benchmarking, by any means.  I just don't think they are accurate enough to make a less than 5% call.  1% is well outside their limits of accurate measurement. :)

 

HH
 


Edited by hhos, Tue Jan 8, 2019 8:44 AM.


#69 mizapf ONLINE  

mizapf

    River Patroller

  • 3,474 posts
  • Location:Germany

Posted Tue Jan 8, 2019 8:11 AM


I don't say that emulators are useless for benchmarking, by any means.  I just don't think they are accurate enough to make a less than 5% call.  1% is well outside their limits of accurate measurement. :)

 

MAME does.

 

I did measurements with my real Geneve side-by-side with MAME on my PC, and I am getting matching values for instruction timing and memory access within less than one percent. Believe it or not.  :P

 

(To be precise: It is the sum of timings that matches; it is not every single instruction per se. MAME just promises to execute an equal amount of instructions between macroscopic timing events as the real iron.)


Edited by mizapf, Tue Jan 8, 2019 8:14 AM.


#70 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Tue Jan 8, 2019 11:13 AM


Your mod has 64K RAM and only 32K is used?  Did they put some of the extra memory into that space, or do you still only have 256 bytes in the >8000 to >83FF address area?

 

I don't say that emulators are useless for benchmarking, by any means.  I just don't think they are accurate enough to make a less than 5% call.  1% is well outside their limits of accurate measurement. :)

 

HH
 

It seems to me there was a modification that let you use all 64K somehow. Since that wouldn't be compatible with a "normal" TI99 I didn't pursue it.

 

I would concede 5 % accuracy, as long as we're talking about the right 5%. For example, 1% faster +-5% would be .95% to 1.05% faster, not -4% to 6%. The first is useful and jibes with my observations while the second is not useful.



#71 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,420 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 8, 2019 3:32 PM

 

MAME does.

 

I did measurements with my real Geneve side-by-side with MAME on my PC, and I am getting matching values for instruction timing and memory access within less than one percent. Believe it or not.  :P

 

(To be precise: It is the sum of timings that matches; it is not every single instruction per se. MAME just promises to execute an equal amount of instructions between macroscopic timing events as the real iron.)

 

To be fair, I did a /weekend long/ test of MESS, JS99er, Classic99, and two hardware consoles (F18A and 9918A), all running the same software in the same field of view (so I could take a photo and read the cycle counts at the same time). I figured the duration was reasonable to minimizing microscopic timing jitters in the emulators and the slight (<1s) variation in startup time. I was trying to validate vertical interrupt times but ran CPU cycles as well (this was while we were working on the Megademo, back in 2016).

 

Per the datasheets for the 9900 and 9918A, the CPU clock should be +/- 5% (a large range!), while the VDP should be +/- 0.05% (accuracy was necessary for NTSC video generation).

 

For the test, I marked my 9918A console as the benchmark, so its CPU and VDP baselines were considered 100%. For the record, the VDP output was 59.917 fps.

 

The F18A machine ran the CPU at 100.02% (well within limits) and the VDP at 59.526 fps. Matt has recently discovered this variation was the cause of some of the ColecoVision issues and fixed it!

 

MESS was by far the closest emulator (and this is why I quoted you ;) ), running the CPU at 99.99% (so closer to the first machine than the second machine was!) and the VDP at 59.924fps (0.01% difference - within spec!)

 

Classic99 and JS99er were both outliers then (CPU and VDP both fast on both, but within 5%), but I've done a lot of work on Classic99 since 2016, and JS99er has seen a number of revisions. MESS is also now MAME. It might be fair to run another weekend test. ;)


Edited by Tursi, Tue Jan 8, 2019 3:33 PM.


#72 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Tue Jan 8, 2019 8:14 PM

The speed that Classic99 runs is a bit complicated for me. The new version of Classic99 (399.004) is about 10% slower. 398 was around 7% slower. BUT, remember that this is running on a Linux system using Oracle Virtual Box and running Windows XP.

Version 398 running in Linux using wine is about 1% faster. (This was about 7% slower in the Linux/Virtual Box/XP combination)  If the clipboard worked with wine I would probably be running this way, but I can't figure out how to make it work.

 

Clearly there is overhead that is slowing it down a bit for me. None of this particularly troubles me. Any of these options are close enough for daily use, and are perfectly adequate for comparing speeds. Now if you ran a program on the 16 bit bus in Win994a, on the 8 bit bus in Classic99, and without expansion memory on a real TI you would not get a meaningful comparison. But as long as you use the same emulator then the comparison will be useful.



#73 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,420 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jan 8, 2019 10:49 PM

Yeah, fair enough. You are probably hitting the same system strain that people used to suffer from about 15 years ago - the video system. Classic99 is /really/ hard on the video system, much more so than most (all??) emulators. This is because it renders internally at a fixed bitdepth, and makes the OS handle conversion to the actual bitdepth. These days there's a lot less going on, IIRC I render at 32-bit and most displays are 32-bit... plus most displays are heavily accelerated. But when VirtualBox comes into the mix, there's some translation going on there that is probably slowing it back down again. The timing system is also a bit pushy, and depends both on Windows honoring its requests pretty closely and getting accurate cycle counts of the performance counter API - another thing that a VM might be filtering. Sorry it's not working that well for you!

That said, if all you want to know is performance between two different tasks, you /could/ just set a timer in the debugger, and let Classic99 tell you how many cycles it took. As of my last pass through that system Classic99 matches hardware, so the numbers are certainly meaningful. While you can't change the bus width in the emulator, you CAN run code from scratchpad, and then run the same code from the 32k expansion, and you'll see the actual difference. No stopwatch needed!

But I get the feeling the discussion is kind of academic ;)

#74 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Wed Jan 9, 2019 7:23 AM

 Sorry it's not working that well for you!  Au contraire, mon ami, it is working just fine for me!

That said, if all you want to know is performance between two different tasks, you /could/ just set a timer in the debugger, and let Classic99 tell you how many cycles it took. As of my last pass through that system Classic99 matches hardware, so the numbers are certainly meaningful. While you can't change the bus width in the emulator, you CAN run code from scratchpad, and then run the same code from the 32k expansion, and you'll see the actual difference. No stopwatch needed!  That is very useful, especially in comparing two pieces of assembly code, one designed for compactness and the other for speed. (I may use that on the latest addition to the compiler. There is a short snippet of code that is used a lot. If I extract that and do a BL sub I can save some code; if I duplicate it I can save some time.)  But the problem here is in comparing an XB program on the fast bus vs on the slow bus

But I get the feeling the discussion is kind of academic ;) Now that is the understatement of the day!



#75 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,420 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Jan 9, 2019 4:46 PM

But the problem here is in comparing an XB program on the fast bus vs on the slow bus


Not insurmountable! :) But sure, tricky.

For the timer, if you can get the execution addresses for specific XB functions, you can use them to wrap the timing test. (You'd need assembly functions, though... since the timer won't currently time on other hardware...)

The bus width one you can't do in Classic99 right now... I did that on purpose since the wait state modifications were always modified consoles, but I intended to make that configurable in a future update, so someday, perhaps. Unfortunately it's not trivial to even hack into the code right now.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users