Hi All and Leee,
I'm wondernig if anyone has used the ehBasic on a 65816 processor and what kind of succssess there was... Does it need to be in emulation mode to work? Can ehbasic address memory beyond 64K up to the max 16meg?
Also, I was wondering, how detailed does the output code need to be? Does it just need to output characters to the next available spot, go to a new line with a carriage return, or what? Also, how big of a display does it expect?
On another question - what about memory holes? For example, let's say the upper 18K of memory is assigned, 5K boot rom, 3K lower memory I/O/ports, 10K basic. Is there a way to tell basic to not go into where memory holes are?
I'm sorry for all of the questions, but I'm really trying to get my 65816 project off the ground =)
-T
ehBasic on 65816
-
leeeeee
- In Memoriam
- Posts: 347
- Joined: 30 Aug 2002
- Location: UK
- Contact:
Re: ehBasic on 65816
Hello Tony et. al.
I've not run EhBASIC on a 65816 but it should work. Perhaps someone else here has done so and can tell us.
The output code is just a character dump, bytes are dispatched one at a time via the output vector and forgotten. There is no expected dimension on the output device though you can set virtual line lengths and tab sizes using the WIDTH command.
BASIC expects one monolithic area of RAM for code and data storage and I can't see an easy way round that without big changes to the way memory is managed. The only exception to this is if the code is to be ROMmed, in this case the whole of RAM is used for data, but this needs some changes to the interpreter.
To tell EhBASIC where to find it's RAM set Ram_base and Ram_top in the assembly file before assembling.
Good news is that I have a 65816 and I am planning a port to native '816 code with enhancements to support the 16MB address range. The bad news is that I have very little time to devote to that right now due to work (what's left of it) and family commitments.
So now is the time for your "I want it to be able to do this" suggestions, before I actually start the first version.
Cheers,
Lee.
I've not run EhBASIC on a 65816 but it should work. Perhaps someone else here has done so and can tell us.
The output code is just a character dump, bytes are dispatched one at a time via the output vector and forgotten. There is no expected dimension on the output device though you can set virtual line lengths and tab sizes using the WIDTH command.
BASIC expects one monolithic area of RAM for code and data storage and I can't see an easy way round that without big changes to the way memory is managed. The only exception to this is if the code is to be ROMmed, in this case the whole of RAM is used for data, but this needs some changes to the interpreter.
To tell EhBASIC where to find it's RAM set Ram_base and Ram_top in the assembly file before assembling.
Good news is that I have a 65816 and I am planning a port to native '816 code with enhancements to support the 16MB address range. The bad news is that I have very little time to devote to that right now due to work (what's left of it) and family commitments.
So now is the time for your "I want it to be able to do this" suggestions, before I actually start the first version.
Cheers,
Lee.
Re: ehBasic on 65816
I tried EhBASIC on a 65816. While I haven't tested it extensively, I didn't encounter any problems with it in emulation mode. It doesn't work in native mode, even when the m and x flags are both 1 (i.e 8-bit accumulator/memory & 8-bit index registers), because the cold start sequence LDX #$FF TXS sets the stack pointer to $00FF not $01FF. CLEAR, NEW, and RUN use LDX #$FD instead of LDX #$FF but it's still the same problem. There aren't that many TXS instructions in the code, so if you're feeling adventurous you could handle each one specially. I don't know if there are any other problems you would uncover in native mode once you fixed this.
-
leeeeee
- In Memoriam
- Posts: 347
- Joined: 30 Aug 2002
- Location: UK
- Contact:
-
leeeeee
- In Memoriam
- Posts: 347
- Joined: 30 Aug 2002
- Location: UK
- Contact:
Latest news.
EhBASIC V2 is nearly finished, this brings some changes to the way it handles eveluating values and removes some undocumented features from V1.xx that remain.
As for the 65816 version I do have a 65816 system with 4MB of RAM that seems to be working but no real code yet. I'm planning to port EhBASIC68 to the '816 which should be better being a 32 bit interpreter. Both versions can run the same BASIC code but the 32 bit version supports longer strings, bigger arrays and more memory.
For those who are interested in the 68k family V3 of EhBASIC68 is nearly complete which gives a fully relocatable and re-entrant (i.e. pure, suitable for multitasking) code interpreter.
All that and I'm trying to move house and get a new source of income now I'm unemployed. Something a little more regular than acting in TV and film (I'm in the new Demi Moore film 'Half light', probably in the deleted scenes section on the DVD, pah!).
Lee.
EhBASIC V2 is nearly finished, this brings some changes to the way it handles eveluating values and removes some undocumented features from V1.xx that remain.
As for the 65816 version I do have a 65816 system with 4MB of RAM that seems to be working but no real code yet. I'm planning to port EhBASIC68 to the '816 which should be better being a 32 bit interpreter. Both versions can run the same BASIC code but the 32 bit version supports longer strings, bigger arrays and more memory.
For those who are interested in the 68k family V3 of EhBASIC68 is nearly complete which gives a fully relocatable and re-entrant (i.e. pure, suitable for multitasking) code interpreter.
All that and I'm trying to move house and get a new source of income now I'm unemployed. Something a little more regular than acting in TV and film (I'm in the new Demi Moore film 'Half light', probably in the deleted scenes section on the DVD, pah!).
Lee.
As out SBC is nearing completion and we're very much intrested in using EhBASIC on it. We, or I anyway, have couple of things that I'd be intrested in knowing.
Firstly, how is EhBASIC in terms of retargetability? We would have the need to be able to load the interpreter into any given memory location and have it run from there?
Secondly, in regards of the above, can EhBASIC be told from where the memory area we're wanting it to use starts from and where it stops to dynamically when it is loaded or are those values hard-coded and require a compile if altered?
As a test code to run on our SBC design, these two things do not matter much because the purpose is to make it act just like those n+1 80s home-computers, but once the Firmware and OS are starting to take shape, they do become important factor in a multitasking system like ours is going to be.
Thanks.
Firstly, how is EhBASIC in terms of retargetability? We would have the need to be able to load the interpreter into any given memory location and have it run from there?
Secondly, in regards of the above, can EhBASIC be told from where the memory area we're wanting it to use starts from and where it stops to dynamically when it is loaded or are those values hard-coded and require a compile if altered?
As a test code to run on our SBC design, these two things do not matter much because the purpose is to make it act just like those n+1 80s home-computers, but once the Firmware and OS are starting to take shape, they do become important factor in a multitasking system like ours is going to be.
Thanks.
-
leeeeee
- In Memoriam
- Posts: 347
- Joined: 30 Aug 2002
- Location: UK
- Contact:
To be honest the 65816 port of EhBASIC is not going well.
I decided not to use the 6502 version as the base as extending from an 8 bit base is awkward at best and it is too tempting to hold onto bits of code that, while they work, will probably cause problems later.
What I have done is started from the 680x0 version, which is now fully relocatable and reentrant, and am trying translate that to something the 65816 can handle.
If it works this will be suitable for a multitasking environment even in ROM form. Of course it has to work first.
When I was working I could usually find a couple of hours a day to work on projects, now with trying to find a job, move house and be a single parent there just doesn't seem to be the time.
Cheers,
Lee.
I decided not to use the 6502 version as the base as extending from an 8 bit base is awkward at best and it is too tempting to hold onto bits of code that, while they work, will probably cause problems later.
What I have done is started from the 680x0 version, which is now fully relocatable and reentrant, and am trying translate that to something the 65816 can handle.
If it works this will be suitable for a multitasking environment even in ROM form. Of course it has to work first.
When I was working I could usually find a couple of hours a day to work on projects, now with trying to find a job, move house and be a single parent there just doesn't seem to be the time.
Cheers,
Lee.
I've been attempting to run EhBASIC on the SBC-3 in emulation mode, changing to native mode to call the ROM. Have moved a bunch of zero-page stuff out of where the SBC-3's I/O goes. At the moment I'm getting a lot of screen corruption (it's not really usable) and it responds to every other keypress. But I have made it do Hello World.
I have modified EHBASIC 2.09 to work with SBC-3, running in 65816 Native mode.
Thanks dclxvi for pointing out the TXS issue!
It is not fully tested or complete.
LOAD and SAVE do not work yet.
Warmstart does not work.
EHBASIC is uploaded via XMODEM to address $A000-$C7ED.
RAM used for program space is $0300-$7FFF (this will change later)
You can download the binary and instructions here:
http://sbc.rictor.org/download/ehbasic.zip
As I find time, I'll tweak it and add the missing functions.
Daryl
Thanks dclxvi for pointing out the TXS issue!
It is not fully tested or complete.
LOAD and SAVE do not work yet.
Warmstart does not work.
EHBASIC is uploaded via XMODEM to address $A000-$C7ED.
RAM used for program space is $0300-$7FFF (this will change later)
You can download the binary and instructions here:
http://sbc.rictor.org/download/ehbasic.zip
As I find time, I'll tweak it and add the missing functions.
Daryl
I have written but not tested the code needed to allow Warm starting EhBASIC from SBC-3. I have also written the interface to allow LOAD and SAVE to call the XMODEM transfer routines directly, allowing for file storage and retrieval over the RS-232 link.
I will test this code over the next day or two and report back. Once I am comfortable with the results, I'll post source and binaries on my website.
After my IDE/CF interface is completed, I'll go back and create the necessary links to allow LOAD and SAVE to access the drive.
Daryl
I will test this code over the next day or two and report back. Once I am comfortable with the results, I'll post source and binaries on my website.
After my IDE/CF interface is completed, I'll go back and create the necessary links to allow LOAD and SAVE to access the drive.
Daryl
I'm assuming that a native port of EhBASIC is out of the question then. It looks like effort is concentrated on patching the old 8-bit platform for running on the 65816 in 8-bit native mode.
If you ask me, I think this approach is better for getting it running and upgrading it to proper 16-bit support over time than borrowing from the 68000 version. The 68000 is just too different a CPU architecture to map well onto the 65816.
(Unless, of course, you treat 64 bytes of direct page as virtual 68000 registers.)
If you ask me, I think this approach is better for getting it running and upgrading it to proper 16-bit support over time than borrowing from the 68000 version. The 68000 is just too different a CPU architecture to map well onto the 65816.
(Unless, of course, you treat 64 bytes of direct page as virtual 68000 registers.)