Posted By
Stinaris
on 2022-11-18
09:30:34
 |  CBMPrgStudio 4.0 7x slower output
So I'm still using the IDE for development, but that may be changing......
So I've been developing Apache Of The Dead on CBMPrgStudio 3.14
Discover 4.0 so install that. However my assembled code now runs 7x slower.
Anyone else had any issues like this. Hopefully I'll get time to look at the assembled code and see what's up.
---+ UPDATE +---
Did a quick bit of investigation.
Now I'm really confused. Having removed items that I thought might affect the speed, the code actually operates differently in each version even though they are based on the same source code files.
|
|
Posted By
Csabo
on 2022-11-18
10:37:53
| Re: CBMPrgStudio 4.0 7x slower output
You're writing machine language (not BASIC), right? Assuming yes, what emulator are you running your compiled code in?
AFAIK the assembler should only be resolving addresses and such, so unless I'm way off here, that should not affect the speed of the compiled code at all.
|
|
Posted By
javierglez
on 2022-11-18
10:40:45
| Re: CBMPrgStudio 4.0 7x slower output
That's nice, I thought they had stopped development.
I use 3.14, but it's pretty quirky. I don't know about any really confortable IDE.
Programs written in assembler should translate pretty much straightforward to machine language as long as I know, this can be checked in the emulator's monitor.
|
|
Posted By
Gaia
on 2022-11-20
16:40:48
| Re: CBMPrgStudio 4.0 7x slower output
As far as I can recall there is a possibility to use Kick Assembler, that should work just fine.
|
|
Posted By
Stinaris
on 2022-11-24
04:00:52
| Re: CBMPrgStudio 4.0 7x slower output
Yes I am using assembler.
I know Arthur was planning Kick Assembler integration but I didn't realise it was in version 4.0.
Not had anytime to spend on this, but I suspect it's somehow related to an uninitialized memory location although I can't see where. Once I get some free time I'll continue the investigations.
|
|
Posted By
Mad
on 2022-11-27
10:23:42
| Re: CBMPrgStudio 4.0 7x slower output
Did you look for $ff13 (one bit there "makes your code run" at half of the "normal" speed.).
Another possibility would be interrupts.. Maybe some interrupt you implemented takes all of the time.
One simple trick to debug is by changing border color on different sections of the code to see how much raster time these sections consume.
If you turned on NTSC one screen refresh only has around 250 raster lines.
But actually I think Csabo is right about an emulator problem, if you didn't run totally different code (like you also implicitely suggested).
|
|
