Willsy

Just for the record (and to save people paging back in the thread!) I have re-posted Lee's code above. Note Lee was using HEX so all literals would be recognised as hex numbers, so his code is correct as written. That said, Lee, I could not get your code to fail, using Classic99 and TF V1.1, as you can see below. Suggest you re-run your experiment. Very puzzling. Perhaps it's the voltages? Of course, TF was only tested on 240V AC systems. Correct operation cannot be guaranteed on 110V systems

At the moment it uses it for the speech synth driver. The idea is to be able to feed data to the speech synth while your program runs instead of your program just freezing up like in Xb... Of course, when not speaking it just returns back to the isr...

That's a good point, Klaus! It;s ikely the F18 will go through a couple of Iterations before it's finally finished. I know Matthew180 said he had a few more ideas. That's the neat thing about programmable logic. Good idea about using the cassette port. Did you de-solder the cassette connector? How did you secure the VGA connector to the case? Can you send a picture? Thanks Mark.

I just pimped my console with the F18A - works a treat! Here's TF running in 80 columns. Note how the block editor reconfigures itself to work in 80 columns - the "windowing" feature that is required in 40 column mode is disabled, and the whole 64 columns of the block are displayed. Neat. Parsec looks awesome on a VGA screen!

Yep. That'll do it. If you don't want to use $ for hex numbers, then execute HEX first: HEX : RANDOMIZE 8802 [email protected] DROP 0 BEGIN 1+ 8802 [email protected] 80 AND UNTIL . ; DECIMAL I also checked with TF V1.1 on real iron (with an F18 fitted, no less ) and it worked fine - a different number each time. I would there propose to make the definition of RANDOMIZE (in TF) as follows: : RANDOMIZE 8802 [email protected] DROP 0 BEGIN 1+ 8802 [email protected] 80 AND UNTIL $83C0 ! ; Which should dove-tail neatly with Lee's RND routine published above. Mark

Just for the record, interrupts in TF are enabled in only three cases: 1) Just before a write to VDP with VSBW 2) Just before a call to JOYST 3) When on the command line (i.e. the cursor is flashing) In both cases it's a simple LIMI 2 LIMI 0 sequence. I would have liked to have had it such that interrupts were pretty much free running, but I couldn't get it to work. Therefore in TF, if you poll the CPU ram version of the VDP status byte in a tight loop, then you'll never see the end of frame bit, because the console ISR never runs and it's the console ISR that updates the CPU memory version of the VDP status byte! Thusly, you would have to poll the VDP status directly. TF is easily fast enough to catch this. For the record, in TF, numbers with a $ preceding them are forced to be evaluated as hex. (numbers with a preceding % are binary). Otherwise the number will be evaluated according to the current setting of BASE (the default is 10 for decimal). The words HEX and DECIMAL can be used to temporarily change BASE whilst compiling. They are immediate words (i.e. they don't get compiled, they just change a setting).

Wow! Awesome - thanks Lee :thumbsup: :thumbsup: Did you try it with idflyfish's litte routine... I'll try it later this afternoon! Thanks for this - much appreciated!

Wow! That is brilliant! I really like the end of the TI one! Trouble is, I am torn... I mean, I really love the TI, and I really love the old rubber keyed ZX Spectrum! I owe my career to both of these computers... Oh the hours I spent locked in my bedroom typing in magazine listings and playing games! Thanks for posting this! :thumbsup: :thumbsup:

That's disappointing. I guess I should have tested it more thoroughly. I suppose we'll just have to live with it as I'm not planning another TF release. Still, if anyone comes up with a decent routine, I'd be happy to produce a CODE version which will run in TF at full assembly speed. Mark

Truth hurts, doesn't it? If you're downloading software that is still under copyright then you are a thief. That's not me saying it, it's the law. The law does not recognize the concept of "abandonware". If you were hauled into court for hosting or possessing illegally obtained software, it wouldn't matter to the judge if it was a new release or if it was 20 years old. It all falls under the same laws and the punishment for the crime is the same. If you don't like the law, then tell someone who has the power to change it instead of acting like a baby who doesn't get his way. Incorrect. Copyright law, specifically in the US was recently updated to specifically recognise abandoned computer software. OWNERS of abandoned software are now legally entitled to make as many copies of the software as they like, wether in contravention of the original licence terms or not. In addition, the law permits owners of said software to circumvent copy protection schemes (dongles et al) in order to back up the software. I suggest you check the Digital Millenium Copyright Act. http://www.joystiq.c...donware-rights/ And here it is from the horses mouth: http://www.copyright.gov/1201/ Note: You still have to own the software under the standard legal definition of 'own'. Piracy is still piracy, and since, as you correctly point out, the copyright on all computer software is still valid, you can't just make copies of copyrighted software to distribute to your friends or sell on eBay; regardless of what eBay might think.

I'm slowly uploading the videos that I shot whilst at the Faire. The video files are huge and take hours to upload. Here's the first few. I'll update as I upload them. Note I have NOT used the real names of the presenters in the videos for privacy reasons. If you are the presenter and would like the video to be removed, or the description updated then please send me a PM. Naval Combat Simulation (Vorticon): http://www.youtube.com/watch?v=0yZYtLyuPDE SID99 Demo: A demo of Marc Hull's gorgeous SID99 card: http://www.youtube.com/watch?v=ouc-fXchz-Y Update on the activities of the European groups: http://www.youtube.com/watch?v=AnqrpuGVOqY HxC Floppy Emulator and the TI-99/4A http://www.youtube.com/watch?v=I4C2wng7vt4 TurboForth V1.1 Demo by Yours Truly http://www.youtube.com/watch?v=BlGqKTZfNxw Austrian User Group Information:

garbage post deleted - the atariage server crashed

garbage post deleted

A combination of boredom and interest led me to ponder on just how 'random' RND is... I.e. is it good enough for the things it would likely be used for (games)? I wrote the following program to test RND: FBUF: clipboard \ define a file buffer called clipboard : TEST \ define clipboard as a DV80 sequential output file pointing \ to the classic99 device CLIP... S" CLIP DV80SO" clipboard FILE \ open the file referenced by clipboard (CLIP)... clipboard #OPEN \ abort if the call to #OPEN failed... ABORT" cant open windows clipboard" 10000 0 DO \ generate a random number... 1000 RND \ convert the number on stack to a string... N>S \ write the string out to the device... clipboard #PUT DROP ( drop fail/success flag) LOOP \ close the file referenced by clipboard clipboard #CLOSE ; The above selects a number between 0 and 1000 and writes the value to the windows clipboard (so this will only work in Classic99) It does this 10000 times. Once we have the data on the clipboard we can paste it into a spreadsheet and graph it: As you can see, there is quite a uniform distribution - as we would expect/hope. There are a couple of holes, but one would expect that they would be filled in given enough iterations. Importantly, the mean line looks spot on - the mean value should be 500 (one would expect?) and it is. So, it looks like it's at least good enough for games, and maybe even your lottery numbers!

That's very interesting. It looks like some sort of flaw in the random number generating algorithm, rather than a bug in the code per-se. I must admit, I don't really know why/what it's doing! The RND code, as posted earlier, looks for a carry and if there is a carry it does an XOR, otherwise it doesn't. That's it. I replaced the HCHAR call with this: 254 RND 768 RND V! Since the 'limit' in the call to RND is even, I expected it to exhibit the same results as your code. However, it worked just fine.

Sorry, that should be Xb not cb - bloody 'phone...

What's the address of the scratch pad memory in cb speak ? Anyone know? Xb had this weird address scheme for CPU memory addresses; some addresses are negative (go figure)

There is a map of how the VDP memory is used by the floppy controller here: http://nouspikel.group.shef.ac.uk//ti99/vdpram.htm There's no point using Classic99 to examine the VDP memory after a disk access, as it doesn't use a "TI" disk controller, and thus doesn't use VDP memory. I used TI994W and I saw some stuff in VDP memory but that also didn't make much sense. You'll probably have to use to a real TI to see whats in the VDP. VDP address >3EEB (number of drive last accessed) looks useful, and also >37DB (CRU base of the controller card). I'm assuming that AFTER a disk access, one could look at >37DB to get the CRU address of the card. You then map DSR at that CRU address in (you'll need a bit of assembly code for that) and from there you can walk the DSR header and extract the device name (DSK, RD, HDS etc). You can then combine the value at >3EEB to make a full device name, i.e DSK1 RD3 etc and append the filename that you want to access. So you end up accessing the file that you want to access, on the device that was last accessed. More investigation will be required on real hardware though to ensure my theory is valid - and even if it is, looking at how the emulators use the VDP (which doesn't seem to adhere to the documented behaviour on Theirry's site) there is a good chance this technique won't work on emulators.

Deleted garbage post.

Yep. For speed in XB its GOTO and GOSUB. That is definately true. I can say though (having written programs using spaghetti GOTOs GOSUBs and SUBs that writing with SUBs is so much nicer. Passing locals into the SUBs is a nice high-level system. But yeah, for speed I can see that you'd want to use GOTO & GOSUB (or, not use XB at all and use something else, like assembler

Wow! Look how fast it is to call a user defined SUB. SEE! I've *always* said people should be using SUBs all the time in XB. Hrmph... Nobody ever listens to me! <sulk>

By the way, I tipped Michael Zapf (maintainer of the 4A emulation in MESS) off about the bug. I know he'd want to know I guess Tursi will read this anytime soon. Very interesting that ALL the emulators do it. I wonder if the F18A exhibits the same problem? Hmmm....

Very interesting stuff Lee! Looks like you found a snag in the emulators - I'm sure Tursi will be interested in that - I should also email Michael Zapf (MESS maintainer) about it too! FWIW, TF initialises the seed at startup from the value in >83C0. If you watch >83C0 in Classic99 you will see it ticking like mad when the TI is on the master title screen or the cartridge selection screen. As soon as you launch TF, the value in >83C0 is frozen at its last value. This becomes the seed for the RND routine in TF. Each time a random number is generated, it is used as the seed for the next call. Here's the code for anyone that is interested. Of course, this could all be done in Forth, but I included it in TF for speed and convenience, as I knew anyone writing a game of any sort will want access to simple random numbers: ;[ RND ( limit -- n) ; pushes a pseudo random number between 0 and limit-1 (rnd MOD limit) ; For the full range (0-65535) use a limit of 0 _rnd clr r6 ; upper part of 32 bit dividend mov @seed,r7 ; seed to lower part of dividend srl r7,1 ; shift r0 1 bit to the right jnc nocarr ; jump if no carry xor @mask,r7 ; calculate new random number using mask nocarr mov r7,@seed ; store it as a seed for next time div *stack,r6 ; divide number by divisor (from stack) mov r7,*stack ; push remainder of the DIV b @retb0 ; jump to push and exit routine mask data >b400 ;] Here's a simple test program (TF V1.1 required) : TEST 1000 0 DO 100 RND . LOOP ; To see how much overhead the screen scrolling adds, try running TEST with the screen scrolling turned off: FALSE SSCROLL ! TEST It's probably 10 times faster

Turboforth v1.1 already does sams although you might not need it at all - Turboforth gives you just over 31k of free RAM on a 32k TI. Take a look at bcd to encode your values in hex strings in xb - one *nybble* per digit. Very simple to encode and extract...

Nothing significant in either of those addresses as far as I know. I think the code is copied from Leo Brodie IIRC...