OSI Basic won't parse commands - syntax error

[AndersNielsen]

I think I finally nailed it down..

I grabbed the tokens from Grant's unified version, pasted them in tokens.s and commented out the macros responsible for generating them.. And now it works! So it was a token table issue after all...

I have to study the macros to figure out why they don't work though - maybe it's a memory map issue.

[floobydust]

First, glad you managed to find the issue and work around it by using some of Grant's code.

As the CMOS version of the 6502 came out in the early 80's, I moved over to it immediately. I still have my original pair of Rockwell R65C02P2 (2MHz) CPUs... and the original accompanying (printed) datasheet. From this moment on, I always took advantage of the additional instructions and addressing modes and never looked back.

As only the CMOS version(s) exist (as new), the only chance of running into the older NMOS parts is acquiring and running older retro machines. As I'm designing and building everything from scratch, I default to the WDC processor and the enhanced instruction set.

I guess you could call WDC Tools proprietary, but it is pretty much the de-facto standard for the 6502, 65C02 and 65C816 processors, being from the same company that designed and still manufactures the CPUs. Of course, there are dozens of others out there as well, so you get to take your pick of the lot, or even write your own. I use WDC Tools for all of my own code and also migrate certain other source code to it when I need to, like Enhanced Basic.

I am using CC65/CA65 on Linux (under VMware Fusion) for compiling Fuzix, but that's a very different source tree which I just use as is for the most part.

Best of luck with your continued work on your SBC... nice bit of kit overall.

[AndersNielsen]

floobydust wrote:

First, glad you managed to find the issue and work around it by using some of Grant's code.

As the CMOS version of the 6502 came out in the early 80's, I moved over to it immediately. I still have my original pair of Rockwell R65C02P2 (2MHz) CPUs... and the original accompanying (printed) datasheet. From this moment on, I always took advantage of the additional instructions and addressing modes and never looked back.

As only the CMOS version(s) exist (as new), the only chance of running into the older NMOS parts is acquiring and running older retro machines. As I'm designing and building everything from scratch, I default to the WDC processor and the enhanced instruction set.

I guess you could call WDC Tools proprietary, but it is pretty much the de-facto standard for the 6502, 65C02 and 65C816 processors, being from the same company that designed and still manufactures the CPUs. Of course, there are dozens of others out there as well, so you get to take your pick of the lot, or even write your own. I use WDC Tools for all of my own code and also migrate certain other source code to it when I need to, like Enhanced Basic.

I am using CC65/CA65 on Linux (under VMware Fusion) for compiling Fuzix, but that's a very different source tree which I just use as is for the most part.

Best of luck with your continued work on your SBC... nice bit of kit overall.

I didn’t know Chuck Peddle ever worked for WDC?

A lot happened from 1975 to 1983 and the C02 is superior in almost every way, but if you go for a universal design you have to take the millions of 6502s out there into consideration. There are more of them available on the market than will ever be new WDC65C02S’s
My project is all about making it easy to use the IC’s you already have - or can easily get - without buying new.
I’m sure the people who actually need new IC’s with warranty will appreciate them not being gulped up by hobbyists

Also considering the active development and thousands of users I’d say cc65 is closer to a “defacto standard” in this century. I haven’t tried WDC-tools - maybe they’re better in some way.

Thank you so much for the help and support floobydust!

[GARTHWILSON]

AndersNielsen wrote:

There are more of them available on the market than will ever be new WDC65C02S’s

Most of WDC's W65C02Ss are invisible, being at the heart of ASICs, and there are apparently many hundreds of millions of them out there. WDC licenses the intellectual property to manufacturers to do that, and I understand licensing fees are less the 1% of ARM's. Mike Naberezny (owner of 6502.org) de-capped the microcontroller in the instrument panel of his VW Jetta in a project to integrate a control-and-information center for his car, and found that there was a 65c02 in it.

[AndersNielsen]

GARTHWILSON wrote:

AndersNielsen wrote:

There are more of them available on the market than will ever be new WDC65C02S’s

Most of WDC's W65C02Ss are invisible, being at the heart of ASICs, and there are apparently many hundreds of millions of them out there. WDC licenses the intellectual property to manufacturers to do that, and I understand licensing fees are less the 1% of ARM's. Mike Naberezny (owner of 6502.org) de-capped the microcontroller in the instrument panel of his VW Jetta in a project to integrate a control-and-information center for his car, and found that there was a 65c02 in it.

Well it's either that or an 8051 - but for DIP-40's the majority has certainly already been made.

Speaking of the 8051 I saw somewhere that it's popular in Asian brands because it's too old to require licensing - I wonder why the same isn't true for both the 6502 and the C02?

[GARTHWILSON]

AndersNielsen wrote:

Well it's either that or an 8051 - but for DIP-40's the majority has certainly already been made.

Speaking of the 8051 I saw somewhere that it's popular in Asian brands because it's too old to require licensing - I wonder why the same isn't true for both the 6502 and the C02?

Well, WDC does still own and license the intellectual property. These are not 40-pin DIPs though. ASIC="application-specific IC," IOW, a custom IC, and these have the memory, I/O, and other microprocessor support, all on the same IC, and the ROM is usually mask-programmed, ie, the programming is in the manufacturing process. I wouldn't doubt if many of them today are even in BGA packages; otherwise, certainly in fine-pitch SMT packages. We got word probably ten years ago that the fastest of them was running over 200MHz.

[AndersNielsen]

By the look of it the original “topography” of the 6502’s probably aren’t protected by law anywhere. So I’m still curious what the difference is. Maybe it’s a matter of upgrades and newer process nodes.
https://eur-lex.europa.eu/EN/legal-cont ... ducts.html

From what I hear the benefit to using a 6502 core instead of an ARM core is the physical die size - simply less transistors. I guess it’s also not worth cloning anything if licensing is cheap enough and you get a “drag and drop” cpu core.

[floobydust]

AndersNielsen wrote:

floobydust wrote:

First, glad you managed to find the issue and work around it by using some of Grant's code.

As the CMOS version of the 6502 came out in the early 80's, I moved over to it immediately. I still have my original pair of Rockwell R65C02P2 (2MHz) CPUs... and the original accompanying (printed) datasheet. From this moment on, I always took advantage of the additional instructions and addressing modes and never looked back.

As only the CMOS version(s) exist (as new), the only chance of running into the older NMOS parts is acquiring and running older retro machines. As I'm designing and building everything from scratch, I default to the WDC processor and the enhanced instruction set.

I guess you could call WDC Tools proprietary, but it is pretty much the de-facto standard for the 6502, 65C02 and 65C816 processors, being from the same company that designed and still manufactures the CPUs. Of course, there are dozens of others out there as well, so you get to take your pick of the lot, or even write your own. I use WDC Tools for all of my own code and also migrate certain other source code to it when I need to, like Enhanced Basic.

I am using CC65/CA65 on Linux (under VMware Fusion) for compiling Fuzix, but that's a very different source tree which I just use as is for the most part.

Best of luck with your continued work on your SBC... nice bit of kit overall.

I didn’t know Chuck Peddle ever worked for WDC?

A lot happened from 1975 to 1983 and the C02 is superior in almost every way, but if you go for a universal design you have to take the millions of 6502s out there into consideration. There are more of them available on the market than will ever be new WDC65C02S’s
My project is all about making it easy to use the IC’s you already have - or can easily get - without buying new.
I’m sure the people who actually need new IC’s with warranty will appreciate them not being gulped up by hobbyists

Also considering the active development and thousands of users I’d say cc65 is closer to a “defacto standard” in this century. I haven’t tried WDC-tools - maybe they’re better in some way.

Thank you so much for the help and support floobydust!

Needless to say, Chuck Peddle did not work for WDC. Then again, the core team were at Motorola, then left to form MOS, which Commodore bought and eventually ended up with Bill Mensch at WDC. Not sure if you've seen the site that Terry Holdt's daughter put together, but it's an interesting read:

https://www.team6502.org/

As far as dev tools go, most have pluses and minuses, you simply pick your poison and move forward. Most folks here have their preferences and some actually opted to write their own instead. When I got back into the 65xx back in 2013, I decided to get a license for WDC Tools (before I found 6502.org) and it's been a good investment for $50. It has some bugs as well, which I've found two over the years, but have also come up with workarounds. TIDE is not very good, to the point where WDC removed it in the free version. Oddly, I still use it for most of my projects, as I've managed to work around those shortcomings as well.

Using old chips is fine... I've got boxes of them, but haven't used them in new projects for various reasons. My current 65xx projects use the W65C02 and that's it from the 65xx chip family. We're just building 65xx projects from opposite sides... all good.

Continuing having fun with your projects, all the best!

[Dr Jefyll]

AndersNielsen wrote:

I guess it’s also not worth cloning anything if licensing is cheap enough and you get a “drag and drop” cpu core.

There's a lot of 65xx "DNA" out there, and I'm guessing that some of it was licensed and some not. NEC and Mitsubishi are among the companies that introduced 65xx-ish product lines (microcontrollers, IIRC). And then there are items like the one mentioned in this forum thread:

CPU in Furby toy - not a 6502, but a little brother

-- Jeff

[AndersNielsen]

floobydust wrote:

Needless to say, Chuck Peddle did not work for WDC. Then again, the core team were at Motorola, then left to form MOS, which Commodore bought and eventually ended up with Bill Mensch at WDC. Not sure if you've seen the site that Terry Holdt's daughter put together, but it's an interesting read:

https://www.team6502.org/

...

Thanks for the reminder - there's a bunch there I've meant to check out more deeply than just watching the video

Dr Jefyll wrote:

AndersNielsen wrote:

I guess it’s also not worth cloning anything if licensing is cheap enough and you get a “drag and drop” cpu core.

There's a lot of 65xx "DNA" out there, and I'm guessing that some of it was licensed and some not. NEC and Mitsubishi are among the companies that introduced 65xx-ish product lines (microcontrollers, IIRC). And then there are items like the one mentioned in this forum thread:

CPU in Furby toy - not a 6502, but a little brother

-- Jeff

I guess it's also not the last architecture to go to when deciding to "make your own".

I'm super excited about reverse engineering toys and putting them to alternative use ...
like this: https://hackaday.com/2013/05/24/tamagot ... gineering/

Not bad if you can get a 1$ toy to do your 6502-bidding!

I'm don't have a long term plan for what to do with MSBasic on my SBC but I decided to get it running because I've see a bunch of people seem appreciative of the retrocomputers that do - though I think I'd prefer a resident assembler myself.
In Basic I'm missing my monitor's cursor a bit but I don't really feel like moving it to my T1 ISR. I guess I could make it part of the MONRDKEY loop while waiting for a character.

How did Basic games work back in the day? Were they all dependent on the system they ran on and relied on the specific kernel routines and writing to straight to the framebuffer?

For now I just added scrolling to my monitor - on a page basis. Since I have four lines pr memory page that means going below the last line moves the whole screen up four lines and sets the cursor position to four lines from the bottom.

Any suggestions to make Basic more useful?

I still need to figure out how to fix the token table macros so it's easier to switch between versions..

[BigEd]

You might be interested to learn about BASICODE which is a standard set of tactics to allow programming in a variety of Basic dialects.
https://en.wikipedia.org/wiki/BASICODE

Glad to hear you sorted out your difficulty. The next tactic I was going to suggest was to post your ROM and we could tackle it by disassembly. It's a pity your toolchain didn't give a usefully complete listing file, but there you go - different toolchains have different strengths and weaknesses.

[barrym95838]

I have great respect for those who reduce their workload with complex macros and linked source files, but neither ever "clicked" with me, and I prefer tinkering right down at the lowest levels. If the assembler supports labels, but that's really all the decoration I need to keep my brain happy for my hobby.

[AndersNielsen]

BigEd wrote:

You might be interested to learn about BASICODE which is a standard set of tactics to allow programming in a variety of Basic dialects.
https://en.wikipedia.org/wiki/BASICODE

Glad to hear you sorted out your difficulty. The next tactic I was going to suggest was to post your ROM and we could tackle it by disassembly. It's a pity your toolchain didn't give a usefully complete listing file, but there you go - different toolchains have different strengths and weaknesses.

On page 2 you should find the complete listing attached
Checking out BASICODE

barrym95838 wrote:

I have great respect for those who reduce their workload with complex macros and linked source files, but neither ever "clicked" with me, and I prefer tinkering right down at the lowest levels. If the assembler supports labels, but that's really all the decoration I need to keep my brain happy for my hobby.

The extra complexity should be offset by how useful it is - not sure it makes sense for the tokens.

[AndersNielsen]

AndersNielsen wrote:

I think I finally nailed it down..

I grabbed the tokens from Grant's unified version, pasted them in tokens.s and commented out the macros responsible for generating them.. And now it works! So it was a token table issue after all...

I have to study the macros to figure out why they don't work though - maybe it's a memory map issue.

Of course it had to end up being a stupid little mistake..
After carefully comparing the difference between Grant's version and the original I'm working with, I started overwriting parts because the listing files in cc65 don't expand macros. After a few tries I noticed the segments were not relocatable...
And found out I somehow had the segments swapped in the memory map

At least cc65 macros look a bit less scary to me now and I'm sure I learned a few other things as well