CHOCHI E with USB Power

[BigEd]

Could the ehbasic problem be related to an unimplemented decimal mode??

Cheers
Ed

[Klaus2m5]

Ehbasic uses decimal mode only in HEX$(). This should not affect any floating point results.

You actually said it yourself: viewtopic.php?f=8&t=2209#p20153

And a patch was presented by Lee: viewtopic.php?f=8&t=2209#p20278

[ElEctric_EyE]

Also, I believe Arlet's latest version does have decimal mode working. You're thinking of the 65Org16 Ed!

[Klaus2m5]

That could actually be a problem. I don't see a CLD in the coldstart vector of Enso's EhBASIC. Just do a ?HEX$(123) and repeat your math tests. The HEX$ will clear decimal mode for sure.

The use of decimal mode in EhBASIC for the HEX$() function involves invalid BCD and may still fail. So the patch is recommended.

[Arlet]

Yes, the standard 8 bit core has decimal mode support. It initializes itself with D=0.

[BigEd]

Yes, sorry, my wild guess does seem pretty weak! Post in haste, repent at leisure...
Cheers
Ed

[8BIT]

BigEd wrote:

Mine arrived today too! A bit of messing with minicom and the raspberry pi, and I got the blinky test, the helloworld and the figforth to work... but ehbasic has some funny ideas:

Code: Select all

Ready
PRINT 22/7
 0.34144E+15

Ready
PRINT 4+5
 5.26515E-07

Ready
PRINT 355/113
 5.43216

Cheers
Ed
(I assume sbc.bin will get an update, given Daryl's comments above)
(BTW, I tried running with two stop bits, but that was less successful than running with one)

Hi Ed,

I tried your calculation with EhBASIC from the CHOCHI website and it seems to work correctly for me. Did you ever find anything else wrong?

Code: Select all

?22/7
 3.14286

Ready
?4+5
 9

Ready
?355/113
 3.14159

Daryl

[8BIT]

enso wrote:

8BIT wrote:

... It appears that earlier versions had the bootloader load at $0000. Does that sound right?

Bah, of course. I changed the mapping a while ago. Thanks!

Daryl, please send me the fixed source file/binary I will put it up on the website.

Hi Enso,

Sorry this is late - it's been a busy week!

Here are the fixed files. The sbc.bin file is ready to load into the CHOCHI E. Load address is $F800-$FBA8. That gives a little more room for additional commands. I also fixed the reset code to point the Interrupt/BRK handler vector to the code in reset.asm. Now, a BRK will dump the registers and return you to the monitor.

Daryl

[enso]

Daryl, thank you. I will update the site as soon as I can. I truly appreciate your effort.

EDIT: Posted Daryl's updates to CHOCHI website.

[8BIT]

Happy to help!

[8BIT]

Hi Enso,

I am attaching the sources and bin file for my full SBC2OS, minus EhBASIC. The 65C02 opcodes were removed and the bin file loads on the CHOCHI board ($E000-$F743). This code includes the disassembler and mini-assembler. Both support 65C02 opcodes as I forgot to modify the code, but as long as just 6502 opcodes are used, it will work fine. I may refine the sources to remove the CMOS opcodes at a later date.

Feel free to post on your website if you like.

Daryl

[enso]

Posted on the CHOCHI site. Thanks again!

[BigEd]

8BIT wrote:

BigEd wrote:

... ehbasic has some funny ideas:

Code: Select all

Ready
PRINT 22/7
 0.34144E+15

... it seems to work correctly for me.

(I've been away for a couple of weeks...)
enso said, I think, that I have a mixed-up version of the bitstream. So, not a hardware or software problem!
Cheers
Ed

[enso]

My working theory is that BigEd's board somehow got a polluted bitstream (I've been working with SD-specialized bitstream that was perhaps bogus at the time and was rushing to get a bunch of boards out). I will try to get his board re-flashed with the good bitstream, or replace it if it doesn't work out.

I've been running EhBASIC on every board since then to check for the bug before shipping. So far I haven't found any problems.

[rwiker]

enso wrote:

My working theory is that BigEd's board somehow got a polluted bitstream (I've been working with SD-specialized bitstream that was perhaps bogus at the time and was rushing to get a bunch of boards out). I will try to get his board re-flashed with the good bitstream, or replace it if it doesn't work out.

I've been running EhBASIC on every board since then to check for the bug before shipping. So far I haven't found any problems.

Could it be that BigEd got hold of a corrupted EhBasic or incompatible binary? I had some strange behavior from the fig forth binary which disappeared when I re-downloaded it.

I just brought the original back from backup and compared it with the working one: the original is 6072 bytes while the new one is 6091 bytes.