-
Content Count
3,144 -
Joined
-
Last visited
Posts posted by Willsy
-
-
: TEST 1 GMODE 1 SCREEN 5 3 12 COLOR 7 0 DO I 11 + 0 I 40 + 32 HCHAR LOOP BEGIN HEX DATA 10 FF00 0 00FF 0 0 0 0 00FF 0 0 0 0 0 0 FF00 0 28 DCHAR DATA D 0 0 0 0 0 0 0 FF00 0 0 0 0 0 2C DCHAR DATA 10 00FF 0 0 00FF 0 0 0 0 0 FF00 0 0 0 0 0 0 28 DCHAR DATA A FF00 0 0 0 0 0 0 0 0 00FF 2C DCHAR DATA B 0 FF00 0 0 00FF 0 0 0 0 0 00FF 28 DCHAR DATA D 0 0 FF00 0 0 0 0 0 0 0 0 0 FF00 2C DCHAR DATA D 0 00FF 0 0 0 0 FF00 0 0 0 0 0 FF00 28 DCHAR DATA F 0 0 0 0 00FF 0 0 0 0 0 0 0 0 0 00FF 2C DCHAR BREAK? AGAIN ; TEST
It's a bit quick. Still, plenty of cycles left for other processing I suppose!
-
While we're talking about features, I have one that I think/assume would be fairly trivial to add?
Can we have a 'warm reset'? I.e Reboots the TI but does *not* zero the RAM in the TI. In other words, it would mirror the behaviour of turning off the console, but leaving the PEB switched on? This would make post-mortem crash investigation easier in some circumstances (i.e. buffers would still be present in memory for inspection etc).
So, I would propose to rename the current Reset entry in the File menu to Cold Reset, and add a Warm Reset menu entry as well.
Just to be clear: Clearly *some* memory would be changed in RAM (mostly in pad) even during a warm reboot - there's nothing that can be done about that, that's just the TI running it's ROM
- I'm just talking about skipping the initialisation of memory to 0 during start-up.As a total aside, not associated with Classic99, it's interesting the note the different behaviour of the TI 32K memory card and the SAMS card. When I power up my system with the TI card in (from power off) memory is mostly 0, with the odd FF in there. However, the SAMS memory is almost completely randomised! It's all over the place!
Thanks
-
That would be a nice feature. TI994W has that feature.
-
I don't want to piss off the few that did purchase the card though.
Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me!
My card has died
The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot...Ouch. Try re seating the card a couple of times and /or changing it's location. Also clean the fire hose connection. That audio line path may be dirty/corroded somewhere.
Ooh! Good point, I'll give that a try, thanks!
-
I don't want to piss off the few that did purchase the card though.
Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me!
My card has died
The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot... -
A book, teaching all about Turboforth is in development. I must admit I got distracted and let it languish, but I've started work on it again this week.
I'm now up to 160 pages! -
How about this:
: IF LOVE FORTH HONK THEN ;

-
I just want to give a great big shout-out to everyone in the TI-99 community. Not only do you guys create some incredibly cool stuff that really pushes the envelope for what the system can do and amazes me non-stop, you guys all seem to get along great and everyone contributes in a positive way to everyone else's projects. This is hands-down the best programming group and computer enthusiast group of gentlemen I have ever seen.
to the TI-99/4A crowd for being so cool!Thank's we appreciate it a lot
Hmmm, you are an Atariage site moderator.
Pushing my luck now: Any chance you could add us as a news topic on the Atariage main page. The TI-99/4A and this group can for sure use some publicity

Yeah, that's true. The 4A community is a great community; mostly because we have 'known' each other for years. However, there's not many of us. It would be lovely to get some new blood into the community!
-
Compact routine here :-
http://www.atariage.com/forums/topic/163646-not-prime/page__view__findpost__p__2020385
Wow! I like that one! I managed to implement it with a little extra functionality and fit it into the spare space in bank 1 with 2 bytes to spare!
Thanks
So will you consider a 32K (4x8) ROM for the future version of Turboforth? Here's an idea, perhaps add the possibility for loading screens from ROM.
You could use the remaing space to include a standard library of words with super-duper fast access. I don't think the 64K EEPROMS are that much more expensive than 16K EEPROMS nowadays.
The current TurboForth lineage will end with V1.1 I think. I've taken it as far as I can in 16k.
TurboForth 2.0 will probably be 32 or possibly 64K. If I ever start it. Some of the features:
* Compile Forth code to native machine code (not threaded code) with inlining of certain words (e.g DROP DUP SWAP etc would be inlined).
* Multi-tasking
* Bitmap mode
* A full suite of DOS words built in (DIR, COPY, TYPE, FORMAT etc)
* Save/load memory image files
It will essentially be a self contained alternative operating system on a cartridge.
Marc Hull's idea of a multi-banked cart with RAM on it is the target (for me). Multi-tasking requires each task to have its own set of private variables, which can eat RAM, so the idea of 4K of ram in the cartridge is attractive.
Since Marcs cart contains Flash memory, you could also load/save/edit code to 'virtual blocks' contained in the Flash memory chip. You would have access to around 200 blocks actually on the chip, living inside the cartridge. If these were compiled and BSAVED then they would load instantly. :-)
We'll see.

-
Compact routine here :-
http://www.atariage.com/forums/topic/163646-not-prime/page__view__findpost__p__2020385
Wow! I like that one! I managed to implement it with a little extra functionality and fit it into the spare space in bank 1 with 2 bytes to spare!
Thanks
-
Thanks!

-
Does anyone have any suggestions for a random number generator in assembly language? A routine that generates a number between 0 and 65535 would be fine.
I'm not satisfied with the Forth routine I have been using in TurboForth, so I'd welcome any suggestions.
If anyone has any ideas, and the routine is short enough, I'd like to add it to the TF V1.1 code.
I'll check MicroPendium etc but I thought I would give a shout out in case anyone has code already done, that they don't mind sharing.
Cheers
Mark
-
May the Forth be with you.
Okay...now we need a t-shirt
Like this one? They're bloody expensive though - I don't set the prices, unfortunately. I ordered one for myself, so we'll see how it goes. I was going to get some done as gifts, but they're just too expensive... I looked at CafePress also, but their editor is rubbish

-
Okay. I'm emulator only, so when things get stuck, I'll just reset the emulator. And then I didn't know/expect having to hold the "break" for a while. All good.

No problem
- the only reason you have to hold break for a while is that I am only testing the break key at the end of the loop 
-
That's by design. You can only "break" a program in TF if the program designer allows it

There are two words associated with breaking a program:
BREAK? ( -- )
Scans for FCTN+4 and terminates the program immediately if detected.
(So, with BREAK? TF will stop the program for you)
TERMINAL? ( -- true|false )
Scans for FCTN+4 and pushes TRUE if detected, else FALSE.
(So, you can *detect* a break condition, and then decide what to do in your code)
: BREAK-TEST 0 BEGIN DUP . 1+ BREAK? AGAIN ;
: TERM-TEST 0 BEGIN DUP . 1+ TERMINAL? ABORT" Break was pressed - see ya!" AGAIN ;
(in this code, the true/false pushed by TERMINAL? is fed into ABORT" - look up ABORT" in the gloassary

FCTN+QUIT is disabled, because it is evil!
You can test for it though. KEY? returns 5 when you press QUIT... So...
KEY? ( -- keycode )
: TEST 0 BEGIN DUP . 1+ KEY? 5 = ABORT" Quit was pressed" AGAIN ;

-
Thought I would show some of the programming concepts in TurboForth. Most people will be able to follow this, I hope

1 GMODE 1 SCREEN \ 32 column mode, black screen \ define a hatch shape... : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ; \ set up characters 144 to 248 with hatch pattern... : SET-HATCH 248 144 DO HATCH I DCHAR 8 +LOOP ; SET-HATCH \ execute SET-HATCH \ define a list of colours for our patterns CREATE COLORS \ this creates a dictionary entry called COLORS \ if you *execute* colors, it returns an address to the stack \ we will now compile a list of color values (bytes) directly \ to memory... 2 C, 3 C, 4 C, 5 C, 6 C, 7 C, 8 C, 9 C, 10 C, 11 C, 12 C, 13 C, 14 C, 15 C, \ at this point, we have effectively created an array called \ COLORS. COLORS returns an address, which is the start of the \ list of data compiled above. \ now we will set up the colors using the list... 0 CONSTANT TRANSPARENT : SET-COLORS 14 0 DO I 18 + \ color set number COLORS I + [email protected] \ fetch a color from the list TRANSPARENT COLOR \ set the color with transparent BG LOOP ; SET-COLORS \ execute SET-COLORS \ we can now remove ALL of the above code and data from memory. \ we dont need it any more... FORGET HATCH \ the above removes everything from HATCH downwards from \ memory, by resetting the dictionary pointers appropriately. \ the code below will compile over the top. This is a nice \ 'overlay' technique to save memory. \ scroll directions... 0 CONSTANT LEFT 2 CONSTANT RIGHT 4 CONSTANT UP 6 CONSTANT DOWN \ random number generator... $8379 [email protected] VALUE SEED : RND SEED 31421 * 6927 @ + $8379 [email protected] TO SEED ; \ initialise screen coordinates and character code... 0 VALUE X 0 VALUE Y 144 VALUE CHR \ clear the screen in a fancy way... : WIPE 16 0 DO 0 0 16 12 PANEL LEFT SCROLL 16 0 16 12 PANEL RIGHT SCROLL 0 12 16 12 PANEL UP SCROLL 16 12 16 12 PANEL DOWN SCROLL LOOP ; : KSCOPE PAGE \ clear the screen BEGIN RND 300 MOD 1+ 0 DO \ random repeat loop \ get random x & y for upper left quarter of screen: RND 16 MOD TO X RND 11 MOD TO Y \ display character CHR at x and y: Y X CHR 1 HCHAR \ display in lower left quarter: 23 Y - X CHR 1 HCHAR \ display in upper right: Y 31 X - CHR 1 HCHAR \ display in lower right: 23 Y - 31 X - CHR 1 HCHAR \ add 8 to CHR. if CHR>248 then reset to 144: 8 +TO CHR CHR 248 > IF 144 TO CHR THEN LOOP \ go back to BEGIN until finished WIPE \ clear the screen TERMINAL? UNTIL \ repeat, unless FCTN 4 is pressed PAGE ." Thanks for watching!" CR ;
Just paste into TF and type KSCOPE. Press FCTN 4 to break.
A more compact version of the code, with comments removed follows. Note how the first section of the program is essentially a 'script', and we only retain the second half in memory.
1 GMODE 1 SCREEN : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ; : SET-HATCH 248 144 DO HATCH I DCHAR 8 +LOOP ; SET-HATCH CREATE COLORS 2 C, 3 C, 4 C, 5 C, 6 C, 7 C, 8 C, 9 C, 10 C, 11 C, 12 C, 13 C, 14 C, 15 C, 0 CONSTANT TRANSPARENT : SET-COLORS 14 0 DO I 18 + COLORS I + [email protected] TRANSPARENT COLOR LOOP ; SET-COLORS FORGET HATCH 0 CONSTANT LEFT 2 CONSTANT RIGHT 4 CONSTANT UP 6 CONSTANT DOWN $8379 [email protected] VALUE SEED : RND SEED 31421 * 6927 @ + $8379 [email protected] TO SEED ; 0 VALUE X 0 VALUE Y 144 VALUE CHR : WIPE 16 0 DO 0 0 16 12 PANEL LEFT SCROLL 16 0 16 12 PANEL RIGHT SCROLL 0 12 16 12 PANEL UP SCROLL 16 12 16 12 PANEL DOWN SCROLL LOOP ; : KSCOPE PAGE BEGIN RND 300 MOD 1+ 0 DO RND 16 MOD TO X RND 11 MOD TO Y Y X CHR 1 HCHAR 23 Y - X CHR 1 HCHAR Y 31 X - CHR 1 HCHAR 23 Y - 31 X - CHR 1 HCHAR 8 +TO CHR CHR 248 > IF 144 TO CHR THEN LOOP WIPE TERMINAL? UNTIL PAGE ." Thanks for watching!" CR ;
Enjoy

-
What I want to do today is take a DV80 file and edit it with XB and output a DV 80 file, why does it always end up a 1 sector DV80 file?
The file I have has excess stuff in it from a sector dump like the crap at the front and end, I just want to convert it to data statements.
Why is this so hard to do with Classic99? This program worked like a charm on a real TI.
The only reason I was using my Real TI was Classic99 just will not allow it, what am I doing wrong?
100 OPEN #1:"DSK2.EAASM1",INPUT
101 OPEN #2:"DSK3.EAASM1",OUTPUT
110 LINPUT #1:I$
120 X$=SEG$(I$,10,48)
130 PRINT #2:X$
140 GOTO 110
This is a sample of the DV 80 file:
00000000 FF FF 20 00 20 00 AA 55 20 04 04 20 28 9E 00 00 .. . ..U .. (...
00000010 00 00 00 00 00 00 00 04 10 80 00 00 00 00 00 00 ................
00000020 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 04 10 80 50 50 00 00 00 00 ..........PP....
00000040 20 8B 13 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
00000050 00 00 00 00 00 00 00 00 11 80 00 00 00 00 00 00 ................
00000060 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 02 12 80 00 00 00 00 00 00 ................
00000080 00 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I do not get why this program will not work?
Firstly, you are not closing the file after you have finished writing to it. That is SERIOUSLY bad. You would almost certainly lose records, even on a real TI.
Secondly, it depends how you have set up DSK3. Check out the file options for DSK3.
-
You are not closing your output file (#2) at the end of the program. Why?What I want to do today is take a DV80 file and edit it with XB and output a DV 80 file, why does it always end up a 1 sector DV80 file?
The file I have has excess stuff in it from a sector dump like the crap at the front and end, I just want to convert it to data statements.
Why is this so hard to do with Classic99? This program worked like a charm on a real TI.
The only reason I was using my Real TI was Classic99 just will not allow it, what am I doing wrong?
100 OPEN #1:"DSK2.EAASM1",INPUT
101 OPEN #2:"DSK3.EAASM1",OUTPUT
110 LINPUT #1:I$
120 X$=SEG$(I$,10,48)
130 PRINT #2:X$
140 GOTO 110
This is a sample of the DV 80 file:
00000000 FF FF 20 00 20 00 AA 55 20 04 04 20 28 9E 00 00 .. . ..U .. (...
00000010 00 00 00 00 00 00 00 04 10 80 00 00 00 00 00 00 ................
00000020 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 04 10 80 50 50 00 00 00 00 ..........PP....
00000040 20 8B 13 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
00000050 00 00 00 00 00 00 00 00 11 80 00 00 00 00 00 00 ................
00000060 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 02 12 80 00 00 00 00 00 00 ................
00000080 00 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I do not get why this program will not work?
-
Buffers in the flex interface, or in the console.
I imagine the memory cards, TI and SAMS will use the +12V line in the PEB and regulate it down to +5V so check the voltages on the PEB power rails. This is difficult to do, because you need to do it with the cards in - in other words, the power supply has to be loaded or otherwise it will look like it's fine when it might actually be weak under heavy load.
There's a circuit board of electronics in the PEB associated with the PSU, but I'm not sure what it does.
-
-
I would say it's the 9901 chip.
You really need a multi-meter. You could try examining the solder joints round the male keyboard connector on the motherboard. If you have a soldering iron, melt them and re-make them, in case the 5V or 0V lines have gone open-circuit.
Otherwise, it would be impossible for the *entire* keyboard to not work, since the keyboard is actually a number of seperate circuits IIRC. It's a purely mechanical device, with no electronics on it. So the fact that no keys works at all would tend to imply that
a) The keyboard is not getting a power supply
b) The 9901 is faulty
If it were the 9901, one would expect the whole machine to just lock solid, and not even boot, but the 9901 has to be a suspect in this particular fault.
You can buy two 9901's for $18 plus shipping here: eBay Auction -- Item Number: 220824044636
Mark
-
I'm too wrapped up in the world of Forth at the moment to take anything else on. I'd be happy to do something after that though, probably in about 6 months.
How's the book coming?
Not too bad. Still loads to do though
The problem is that I chose to make it difficult for myself! The book not only teaches all the TurboForth words, it also teaches *Forth*. I considered this essential as most people in the (current) TI community don't know Forth, so without a book to teach them Forth programming they wouldn't be able to do anything more than 'kick the tyres' and then they would lose interest.*Hopefully* the book will show them what Forth *is*, show that it's not as difficult as it looks and encourage people to sit down and give it a good spanking, rather than kick the tyres!
Mark
-
I'm too wrapped up in the world of Forth at the moment to take anything else on. I'd be happy to do something after that though, probably in about 6 months.
-
Woah! Hell of a job RetroClouds! Nice one!
I also added a new function to Classic99. It's called
bool ready=makeCupOfTea(bool sugar);
Sadly, it only works in the UK. My C skills are not up to the job of
YACK ready=cupOfRancidPiss(coffee);
which seems so popular across the pond


Devastator
in TI-99/4A Development
Posted
How do wait for the next frame in assembly? (I can't remember...
)