I'm not sure I grok the code, so I don't really know what needs to be tweaked in order to get the ehbasic system to build for a certain platform.

Let's say I know how to access the OS to open/read/write/close a file, the console to putch and getch and kbhit. (I don't know how to OS access yet, but I'll find out! )

How would I patch that into the binary?

I'm thinking of making ehbasic launch on a ][ under ProDOS as a system file (needs to be loaded at $2000, but can be moved up).

-uso.

EhBASIC isn't really meant to bolt into something like the Apple and I think it's a bit of a stretch to try patching the binary to do that.

If you re assemble EhBASIC it shouldn't be too hard to change it so the program memory starts after the interpreter in memory (but there may be some problems with string functions - I'll need to look into that) so loading at $2000 could be made to work.

The main problem, I think, will be ensuring that ProDOS and EhBASIC don't write all over each others variables as EhBASIC uses a fair chunk of page zero and, I assume, any Apple DOS will do likewise.

I don't have an Apple (any decent emulators out there? with ProDOS would be a plus) or any Apple docs, so can't really help in much more detail.

Lee.

The Apple ][ is easy to emulate. There's a ton of emulators out there for any OS you can imagine. (BTW - I have the source.asm file for your ehbasic, and I was trying to patch it.)

You can try my emulator, Dapple ][ http://sourceforge.net/projects/dapple - or ApplePC (DOS), Apple Oasis (Win 3.1) or AppleWin (Win9x) - they're all pretty good. (Dapple ]['s debugger lets you load code at a specific address. The original Dapple had a feature that let you tack a header onto the file and load it from the file selector.)

If you want ProDOS, I don't have any docs for it, but you can download it from certain places. Maybe it's not the best thing for me to post a URL to Asimov, but here's some stuff - ftp://ftp.apple.asimov.net/pub/apple_II/images/masters/

I'll have to find info on ProDOS. I think it's called with a JSR followed by a DB #$func, followed by a DW $pointer-to-args or something like that.

-uso.

I've been experimenting with EhBASIC lately and decided to try porting it to the Apple II, since I have a lot of Apple tools. As it turns out, it is relatively painless to build a minimally functional system. Here is what I did (the line numbers in parenthesis refer to the source code, version 1.10), which put the EhBASIC interpreter at $6E00-$95FF (just below DOS) and left $800-$6DFF for programs and data:

1. changed Ram_base to $0800 (line 418)
2. changed Ram_top to $6E00 (line 419)
3. changed *= to $6E00 (line 422)
4. commented out the LF ($0A) output (the JSR LAB_PRNA and the LDA #$0A instructions) in the LAB_CRLF routine (lines 2286-2287)
5. uncommented the non halting key input entry in the PG2_TABS table and changed xxxx to A2_IN (line 7606)
6. uncommented the output vector entry in PG2_TABS and changed xxxx to A2_OUT (line 7607)
7. inserted the cold start, input, output, and reset handler routines below.

When it asks you for Memory Size, just type $6E00 (or whatever value you used for Ram_top) and press return. I have not tested EhBASIC extensively, but I was able to enter a number of programs and run them without any problems. A cursor will not be displayed, which is inconvenient, but a cursor is not necessary.

The good news is that there aren't any zero page conflicts to contend with. Parts of the area $1F-$4F are used by the Apple I/O ROM routines, the monitor (at $FF69), and DOS 3.3, but nothing outside that area is used. Luckily, EhBASIC doesn't use anything in the $1F-$4F area. In quickly perusing ProDOS (the MLI), the only part that appears to use any zero page locations outside $1F-$4F is the QUIT command, which is used to restart the system (in which case you'd be cold starting EhBASIC anyway, so who cares what gets overwritten). The only potential conflict I can see is if you use the IIgs and the /RAM5 RAM disk or to the 3.5 floppy drive, because smartport driver in ROM (used by ProDOS) can overwrite some of the memory locations in the $50-$6F area.

Here is the cold start code, which I inserted before LAB_COLD.



Here are the input, output and reset handlers. I chose to have reset drop you into the monitor, but you may wish to take other action. From the monitor, you'll have to cold start EhBASIC with 6E00G since the monitor can overwrite $200-$2FF (its input buffer), and part of that area is used by EhBASIC.



If I was going to build a more usable system (I'm not, but if I were...), I would also do the following:

1. Change all CR ($0D) LF ($0A) sequences to CR, in things like the Ready message, the sign-on message, etc. You could also change the A2_IN routine to print nothing when it sees an $0A, but then you wouldn't be able to print LFs with a PRINT CHR$(10) when you wanted to.

2. Move everything on Page 2 (Ibuffs, ccflag, etc.) to page 3 so that you can drop into the monitor with a CALL $FF69 and return to EhBASIC with 0G

3. Comment out the all of the Memory Size prompting and just use Ram_top for this parameter.

4. In the warm start routine, write a non-zero value to Ibuffs-1 and write a zero to the byte before the one pointed to by Smeml (usually this will be Ram_base). You can really get stuck if these get clobbered by a runaway program or a crash.

5. Add a halting key input vector to allow a cursor to be displayed (which, like the Ctrl-C vector, could simply default to the current behavior). For example, the LAB_1359 loop would be replaced with a JSR V_IN_HALT.

6. Add a line input vector so that additional editing features can be used. For example, a JSR LAB_1357 would be replaced by a JSR V_IN_LINE. Again, this vector could default to the current behavior.

7. Write a custom line input routine which allows ESC sequences, allows the right-arrow to retype, clears to the end of the line when return is pressed, allows the line to be cancelled or cleared (restarted), and displays any control characters entered in inverse (black-on-white) text so that they can be easily spotted.

8. Write a custom Ctrl-C handler. The default Control-C handler calls the A2_IN routine which doesn't allow Control-S to reach the output routines, so listings and other scrolling text can't easily be paused.

9. Fix the line number bug and the FOR bug.

10. Replace the current pseudo-random sequencer with a linear congruential random number generator.

Any reason why you didn't use the Apple II ROM input routines? Either $FD1B or $FD35? (Sorry if it's a dumb question - I've never used EhBASIC and it's been a long time since I really did anything on the Apple II.)

EhBASIC expects an input routine that doesn't wait for keypress (it uses this routine to check if Ctrl-C is pressed, and it can't stop and wait for that) and both $FD1B and $FD35 wait for a keypress. The $FD35 routine was part of what I had in mind with suggestions #5 and #7 (in the second list). I wanted to get EhBASIC working with as little internal surgery as possible, and using $FD35 would require internal surgery. (You could look at the return address determine what called the input routine, but since EhBASIC checks for Ctrl-C at each statement, you want to keep the input routine as quick as possible.) Modification #4 (in the first list) was the only internal routine I modified.

Did you tell me about the undocumented feature in FOR?



I've been working on that. For any integer number range that fits in 0 to 2^n-1 taking the nth value does help as there are 2^n possible results. I'm also trying using this in combination with small a (256 byte) scattering array so that the sequence is still the maximal length.

BTW I have fixed the shift code. 8^)=

Cheers,

Lee.

Oops! I should've noticed that.

Okay, maybe I should have said I wasn't PLANNING to build a more usable Apple II EhBASIC port. Here are a few of the sugeestions I've sucessfully incorporated:



There are CRLF sequences ($0d,$0a) in the following messages: (remove the $0a from these sequences)
a. LAB_SMSG (line 7676)
b. LAB_BMSG (line 8483)
c. LAB_RMSG (line 8486) contains 2 CRLF sequences
d. LAB_IMSG (line 8488)
e. LAB_REDO (line 8489)



a. change Ibuffs to $0323 (line 27)
b. change ccflag to $0300 (line 407)



a. comment out lines 478-523 (JSR LAB_CRLF to LAB_2DB6)
b. comment out lines 526-527 (the CPY #(>Ram_base+1) and BCC LAB_GMEM instructions)
c. changed last entry of StrTab (line 7669) to Ram_top
d. comment out lines 7672-7673 (the LAB_MSZM message)



This only adds the ESC sequences, right-arrow retyping, and clearing to the end of the line when return is pressed.

a. changed JSR V_INPT at LAB_1359 to JSR A2_INH (line 944)
b. commented out the BCC LAB_1359 instruction (line 945)
c. commented out the BEQ LAB_1359 instruction (line 947)
d. inserted the following A2_INH code





This Ctrl-C handler does not check interrupts, so if you use them, replace the RTS with a JMP LAB_FBA2.

a. change the Ctrl-C check vector in PG2_TABS to A2_CC (line 7605)
b. insert the following A2_CC code





Yes, but it was quite a while ago, and I only mentioned that I thought there would be a problem. The problem occurs when the 3 FAC1 mantissa bytes of the number after the TO keyword are $FF and the FAC rounding byte is $80 to $FF. What happens is that the sign bit is incorporated into the MSB of the FAC1 before the rounding byte is rounded into the FAC1. Each of the following behaves as you would expect:

FOR Z=1 TO 16777215: ? Z: NEXT
FOR Z=1 TO 16777216: ? Z: NEXT
A=16777215+.5: FOR Z=1 TO A: ? Z: NEXT

...but to see the U.F. (undocumented feature) in all its glory:

FOR Z=1 TO 16777215+.5: ? Z: NEXT



I've got a linear congruential RNG written and tested. It includes a routine that allows you to plug it into the USR function of EhBASIC. The USR function takes the same argument as the RND function so you can just replace RND with USR in your programs. The heart of the generator is a function called RAND which performs the 32-bit calculation seed = a * seed + c. There are three versions of RAND: a fast version using tables, a short (in terms of number of bytes) version, and a middle version (slightly longer than the short version, but between the other two versions in terms of speed). The multiplier can easily be changed in the first two versions. A JSR RAND in the fast version takes only 94 cycles but uses 4 pages of tables. You can even squeeze two more cycles out of it by using 6 pages of tables.

There are two other functions which are not needed by EhBASIC: RANDOM and URANDOM. RANDOM generates a random number between 0 and arg-1 inclusive. URANDOM does the same, but produces a perfectly uniform distribution. In other words, the sequence length is 2^32 and if you pass RANDOM a number between 0 and 5, some numbers will be a teensy bit (a very teensy bit) more likely than others, since 2^32 is not a multiple of 6. URANDOM makes each possibility equally likely. There are versions of both functions for 8 and 16-bit arguments. All that is left to do is to stop writing long-winded forum posts, document the use of all these functions, and send it to Mike.

In terms of the pseudo-random sequencer, taking every Nth value does help, but fiddling with the randomness of a generator tends to make it worse. Of course, linear congruential generators aren't perfect either. Here is a program that illustrates the limitations of the EhBASIC RNG (with the shift code fixed). Note that as written it uses every 5th random number.



The program attempts to fill a 16 x 16 square. Using only every Nth random number, it generates K x-coordinates, then K y-coordinates, and "plots" them. Every C iterations, it displays the grid. When K=1, the following values of N also fail: N=1, N=2, N=3, N=31. Makes some interesting patterns though, doesn't it?

I did think of using that type of generator but rejected it because for any range less than a it behaves like seed = seed + c



I'm not 'fiddling', I'm doing quite a lot of research on this as it's something that interests me. So far each change is tested to make sure it still generates the maximal length sequence (which I like as an engineer as the spectrum of 0s and 1s is pretty flat). I know what fiddling with RND generators can do and there are some pretty short sequence loops in some standard RND functions.



Aw nuts! How did I manage that? Ok noted and fixed.

Cheers,

Lee.

Really? What values did you use for a and c and m, and which bits of the result were used (i.e. upper, lower, middle, etc.)? My actual calculation is seed = (a * seed + c) MOD m, where c = 1 and m = 32. The upper bits of the result (from bit 31, working downward) are used. I've used 1664525 and 69069 for a, and it certainly doesn't behave anything like seed = seed + 1. Knuth lists a lot of little rules, e.g. using int(N * seed / m) to get the new random number, and I've tried to incorporate all of them into my routines.



Okay, fiddling may be too strong a term. But while taking every Nth value helps, I'm not sure that crosses the threshold between "limited generator" and "better generator". I'm certainly no random number expert, but I have experimented quite a bit with pseudo-random sequencers, although I don't know much of the theory about them. I really wish they were better generators, because they're fast, they're very easy to implement in hardware (a shift register and an xor gate), and they can be easily ported from one processor to another, but it's not to be, I guess.

I can't claim to be personally wild about ANY random number generator, but a linear congruential generator is my "favorite". The best solution seems to be a choice of random number generators.

I looked at your prng a while back (so it may well have changed since) and it struck me as sort of odd.
As I recall you generated the sum (XOR) of the bits by incrementing a counter. That seemed a little clumsy.
(I hope you'll forgive the word, I don't mean to be insulting) (and maybe there was some good reason
for it that I missed?)
You might consider a Galois type LFSR if you haven't already.

Also, you might be interested in some of the writings of Pierre L'Ecuyer

here's a couple that I found interesting:

"UNIFORM RANDOM NUMBER GENERATORS: A REVIEW"
http://www.informs-cs.org/wsc97papers/0127.PDF

"Maximally Equidistributed Combined Tausworthe Generators''
http://www.iro.umontreal.ca/~lecuyer/my ... /tausme.ps
http://citeseer.ist.psu.edu/25662.html

(the combined Tausworthe generators are, basically, LFSRs XORed together)

he gives tabulations of combined Tausworthe generators

http://citeseer.ist.psu.edu/29889.html

although the ones I recall were aimed at 32 and 64 bit machines
I believe he mentioned some for 16 bit machines somewhere

More of his stuff here:

http://www.iro.umontreal.ca/~lecuyer/papers.html

and on Citeseer

I guess the forum software got indigestion or for some reason rejected my post, so this is the second time I'm writing it. I hope it doesn't show up twice now.

If you have a counter running like T1 in a VIA free-running off of phase 2, you can use its count in the construction of the seed. Since you don't know what the count will be the next time you need a random number, using it in the seed will result in a truly random number.

There's just one thing to be careful of. If you're having it generate an interrupt every time it rolls over, reading the counter makes it stop asserting the interrupt; so if the interrupt hits during the instruction to read the counter low byte, the ISR will start, but it won't find the source of the interrupt.

I couldn't think of a shorter/faster way to do it at the time, it is a little clumsy. It's better now.


No clumsy was right.


I must admit I wasn't familiar with that type. Assuming all the feedback bits are in one byte it would be the fastest yet, with just a branch and a possible XOR.

Lee.

I went to your website and downloaded the source but it looked the same to me,
is there a more recent version somewhere? (this says 07/14/03)

I think Galois LFSR type would be fastest but for future reference..

Noting that:

1) A simple arithmetic sum of two bits is the same as XORing them.
2) You can propagate bits through a word using carries.

like so:

d00a
0111

and the sum has a xor d in the d bit position



You can collect the bits of a word and XOR them together (generate parity for the word)
at the same time

like so (pseudo assember):


and end up with the parity in the high bit.

If you want to XOR bits across more than one byte you just have to start with the bytes
XORed together in WORD

Of course, you wouldn't have to go through all that if you're doing an LFSR with just two bits in the
feedback term. However that paper on combined Tausworthe generators says:

"recurrences based on polynomials with too few non-zero coefficients are known to have important
statistical defects" (and gives references)

So you probably want a more complex polynomial any way

My impression (but I'm no expert) is that a 32 bit prng is way too short to be much good (which is
why he (Pierre L'Ecuyer) combines them)

His approach is to pick component generators that make it easy to analyze
so he can show a good distribution of bits and no simple systematic defects and then
use only a small part of the total cycle.

Unfortunately, the PRNGs he's analyzed really need barrel shifts, and so might be a bit awkward
on the 6502.

Note that if you take two LFSRs with mutually prime cycle lengths, and combine them, the total
cycle length is the product of the two.

Also (if I'm reading that paper right, and it's over my head) the combined generator can be
equivalent to a much bigger generator with with more bits in the polynomial sort of like doing
a few bits of the polynomial at a time and on shorter words.

So you might, for example, do some general code for doing LFSRs that you could pass different
polynomials to as parameters and use it to run several LFSR's at once then combine them.

(and if it were me doing it, it would be by guess and by golly, so I'd test the shit out of it )


As a side note, I thought it interesting that he classfies LFSRs and linear congruential generators
as special cases of the same thing.