6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 8:45 pm

All times are UTC




Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Thu Jun 01, 2017 9:28 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
8BIT wrote:
I think I found the problem...

That's a good bit of detective work!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 02, 2017 3:29 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Good catch, Daryl! I will eventually (when I return home in about 6 weeks) add this to my EHBasic bugs and quirks text. I sure hope this is the last Ibuff bug. :-)

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 4:39 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
GaBuZoMeu wrote:
Thumbs Up !

edit(1):
Now that A is changed (LDA Bpntrl; test for $00) it is perhaps saver to preserve A by adding a PHA past STA IBuffs,Y and unstacking A before DEC Bpntrl .


I traced the code that happens after the RTS of that routine and the first access to the Accumulator was to load it with a new value in both cases, so its safe to use LDA without the PHA/PLA wrapper.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 4:50 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
BigDumbDinosaur wrote:
8BIT wrote:
I think I found the problem...

That's a good bit of detective work!


It was actually pretty easy using the Kowalski Simulator. After seeing that the line input was processing right, I figured I could trace a LIST command to see why it was not working.

I got it to the point that I typed LIST after entering Line 10 and then went into debug mode. I injected the CR and then just single stepped the code until I got to a point where I saw the Bpntr get INC'ed to $0500. That jumped out as obviously wrong, so testing that code with different values of Ibuffs was very quick. It took longer to write up the post that it did to find the problem.

I have attempted other bug hunts with much less successful results. It did feel good to find this one. Lee did a great job of commenting the code, which also helped.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 5:03 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
Klaus2m5 wrote:
Good catch, Daryl! I will eventually (when I return home in about 6 weeks) add this to my EHBasic bugs and quirks text. I sure hope this is the last Ibuff bug. :-)


Thanks Klaus for maintaining these. It will hopefully help others not stumble on the same things.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 5:45 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
8BIT wrote:
I traced the code that happens after the RTS of that routine and the first access to the Accumulator was to load it with a new value in both cases, so its safe to use LDA without the PHA/PLA wrapper.

Daryl

Thank you for your further investigation!


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 11:53 pm 
Offline

Joined: Mon Jan 09, 2017 3:50 pm
Posts: 39
Thanks for figuring this out.

Here's another one :)

Write a simple FOR I=0 TO 1000, PRINT I, NEXT I loop.

Run it and while it's running (and printing out the values of I), press a key. The program will stop and freeze.

Is that expected?

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 04, 2017 3:51 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
No, and trying both with line number 10 and RUN and also in Direct mode, it did not stop for me except by doing Ctrl-C, as designed. Can you post your VEC_IN routine and your current memory configuration?

thanks

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 04, 2017 4:00 am 
Offline

Joined: Mon Jan 09, 2017 3:50 pm
Posts: 39
Okay. I figured it out. It was an error on my part (aka false alarm).

I'd left interrupts on the UART enabled. Left over code from the Z80 BIOS (that has a 255-char buffer etc).

I'm really sorry for that.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 04, 2017 4:56 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
No worries! I'm glad you found it.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 06, 2017 6:41 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Just curious, but why did you want to change Ibuffs from it's default anyway?

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 3:28 am 
Offline

Joined: Mon Jan 09, 2017 3:50 pm
Posts: 39
BillO wrote:
Just curious, but why did you want to change Ibuffs from it's default anyway?

Because the comment in the source code is "Ibuffs can now be anywhere in RAM". So I took it to be a porting requirement. Also irq_vec wasn't defined in basic.asm. So you'd hit a build error if you're building a stand-alone BASIC binary.

Anyway, I've "checked in" the forked code at GitHub (https://github.com/ancientcomputing/rc2014/tree/master/source/6502/ehbasic). This is based on the source hosted by Klaus.

Other than the "port" itself plus Daryl's patch, I've added the following:
1. Cold and warm start entry points. This is to make the behavior similar to the old Nascom/MS BASIC that is used in the RC2014 kit.
2. Hardcoded BIOS calls for console i/o
3. Added SYS keyword to exit back to the monitor. I think Daryl is using SYS for his port, so I wanted to stick to that. Otherwise the RC2014 BASIC uses the "monitor" keyword (which actually jumps to reset...).
4. Some clarity (in comments) on what variables need to be on what page in memory :)

Oh and I'm thinking about removing the IRQ/NMI code. Are there any side effects e.g. core BASIC functionality that is dependent on the IRQ/NMI code?

@Daryl, I've used your monitor "lite" codebase to build a simple monitor for the RC2014 6502 board. While I've reused a number of the subroutines, I've changed the user interface a fair bit to produce that same/similar behavior as my Z80 monitor for the RC2014. I've also added a (C) continue command to the BRK handler so that you can actually continue program execution after examining the registers. This is a little simpler than what I implemented for the Z80; primarily because there's essentially only one stack on the 6502. Whereas the Z80 can have a Monitor stack and an application one. So you can hit a breakpoint, go out to the full Monitor, and look at/change memory contents... (Note: not intending to start a CPU religious war here. We know who won: it starts with A :lol: ).

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 11:18 pm 
Offline

Joined: Mon Jan 09, 2017 3:50 pm
Posts: 39
I ran Robert Sharp's prime number program to benchmark the 6502+EhBASIC vs the Z80 with Nascom/MS BASIC on the RC2014.

The latter runs at 14.7456MHz on a custom Z80 board. The 6502 runs on the same RC2014 system but at 4MHz using a CMD part.

To find all prime numbers to 199, the Z80 gave 10.62 seconds (iPhone stopwatch), whereas the 6502 gave 10.82 seconds.

Barring differences in BASIC implementation, this is actually quite consistent from a MIPS perspective: with a 6502 being capable of 4MIPS and the Z80 at 14.7456MHz doing ~3.7 MIPS (4 clocks per instruction) along with somewhat more efficiency etc.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 12, 2017 12:45 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
bluesky6 wrote:
I ran Robert Sharp's prime number program to benchmark the 6502+EhBASIC vs the Z80 with Nascom/MS BASIC on the RC2014.

The latter runs at 14.7456MHz on a custom Z80 board. The 6502 runs on the same RC2014 system but at 4MHz using a CMD part.

To find all prime numbers to 199, the Z80 gave 10.62 seconds (iPhone stopwatch), whereas the 6502 gave 10.82 seconds.

Barring differences in BASIC implementation, this is actually quite consistent from a MIPS perspective: with a 6502 being capable of 4MIPS and the Z80 at 14.7456MHz doing ~3.7 MIPS (4 clocks per instruction) along with somewhat more efficiency etc.

This sort of comparison highlights what we knuckle-draggers have known for years: the 6502 is very efficient at what it does. The Z80: not so much. I won't even go into the interrupt latency angle...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 12, 2017 8:04 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
The way to look at this is to compare the number of memory accesses. The clock speeds of the two CPUs are different because of the different microarchitectures.

I remember when the T9000 was struggling to reach even 15MHz, one of the senior management wondered if we could market it as being 60MHz on the grounds that it ran on a four-phase clock. For sure the emphasis on clock speed in marketing favoured architectures like the Z80 and x86.

Running an application benchmark is a very good way to compare performance - just have to be careful that both versions are coded with roughly equal levels of expertise.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: