jedimatt42

So far so good. No complaints when the FBLOCKS and font files are totally absent. The font file controls work well, as described. My project only needed a tweak to refresh the FBLOCK words I've BSAVE'ed into my own blocks file. But of course, that is to be expected with BSAVE. I'll try real iron tomorrow. [email protected]

That is awesome to see!

Congratulations! And looking forward to it. But of course, no rush. Enjoy the family time. [email protected]

If you posted a beta, I would definitely give it a go. I would try out the different behaviors with the font file, including not having one. And DATA[ in rom would be handy. I currently have the DATA[ words bsaved into my current block file, and I need to re-org my block file anyway, as I didn't give myself enough learning space. [email protected]

http://www.datapro.net/news/faq-how-do-i-go-from-dvi-to-vga.html That IOGEAR model, I'm pretty sure, only handles digital video. So as Mizapf said, a lot of hardware. Amazon thinks it is either $1200 worth of hardware, or $50 http://smile.amazon.com/Format-Hardware-Converter-Convert-Digital/dp/B01AUKRHEG/ref=sr_1_14?ie=UTF8&qid=1460239223&sr=8-14&keywords=vga+to+dvi-d I don't know the quality of that though. [email protected]

Thanks for this guide. Putting a little black raspberry pi next to all of the other little black boxes at the TV is a great way to sneak the TI into the main entertainment center... I did one thing different in my setup.. after installing ti99sim with sudo make install, I linked the cartridges folder instead of copying them. ln -s /opt/ti99sim/cartridges /home/pi/RetroPie/roms/ti99 I had tried to adjust the emulation station config to just look directly in /opt/RetroPie/cartridges, but either I made a mistake, or that just didn't work. [email protected]

There are more things about this that I don't understand, than things that I do. Maybe some questions to help you come to a conclusion: Does the previous SMUDGE change the result of LATEST? You have a comment in your manual that CREATE doesn't behave the same as in Starting Forth. Is this something that snuck in between adopting some fig-forth-isms, and preserving TI-isms? If this was for a modern computer, I'd make the change, and analyze the output, to see if there is any difference. From your description of what is going on, it certainly seems like one is just re-writing the same value to the same location. [email protected]

Since running emulators on the OS X came up several times, I'll just say, I've run Classic99 using Wine on the Mac. There were just a few artifacts with the menus. Classic99 works very well on Ubuntu linux with Wine, except for the clipboard/paste features. That can probably be fixed by messing with Wine more deeply than I bothered to. V9T9 is also a JVM/Java based emulator so it just worked on linux and OS X. And of course MESS/MAME can be had for OS X as well. [email protected]

now having arcadeshopperdotcom on facebook suddenly makes sense to me

It is very interesting to me that the looping is across the destination address. I don't normally think that way, but since the source data is offered at the top of the stack, it makes sense that you can just take them as they are given, and slot them into the place in memory that makes it usable for target word. Yes, an addendum would be great. Regarding tweaks to the manual... I'll try to preserve some notes. The instructions in Chapter 10 where easy to follow for this. What I find particularly nice about this, is that I have variables defined, for things like speed and a mileage counter, that impact how things behave in the ISR, such as how many bytes to shift the character patterns. With the ISR, I just set all that in motion, and then I'm still at the terminal/prompt and I can just store values into those variables and see immediately how it changes. It can eliminate a lot of edit/compile/reload/run cycles. I don't know how to tell how much code can happen before I'm skipping a beat... I might need to implement the clock first, so I have a symptom when I've put too much code in the ISR. [email protected]

Nice! thanks. I didn't notice DCHAR, I'll have to take a look at it. It makes sense to just write words that consume from addresses when using DATA[ instead of coercing it to be on the stack unnaturally. I'll take it as a clue, "if it doesn't fit, I'm doing it wrong" I noticed the ordering issue when I looked at the memory map. Coercing the data onto the stack in the right order is another unnaturally act for the CHAR word. Further reason to look for something like DCHAR. Ah, I wrote something similar to DCHAR, but I used horrible things like 800 instead of PDT. I can retire mine now. Thank you! Looking through the vocabulary in the manual, there just aren't very many words where the usage would be helped by an SALLOT. So maybe now I understand better why it isn't there. BTW: If you ever in the mood to refine the manual, the tips in CHAR and CHARPAT descriptions inform me of the address of the pattern definition table, but ( in my opinion ) should send me to the PDT constant. Thanks again for the help and explanations! Now it's off to clean my code up to use DCHAR. ( I've got an improved 4 sprite layered Formula 1 car, and a smooth scrolling curb, all running out of the interrupt service routine... fun times ) [email protected]

Speaking of DATA[ ]DATA, I'm trying to use them I know this is not the most efficient technique for the specific problem at hand which I will accomplish using VMBW, but I'm trying to learn idiomatic forth. So here goes: How do you do something like ALLOT on the parameter stack without assembly code? ( The fbForth 2.0 manual shows exactly how to do it in assembly code. ) I have something like: : LBANK ( -- addr n ) DATA[ FFF0 F3F6 FFF0 F3F6 FFF0 F3F6 ]DATA ; ( A character pattern I can slide across for a single pixel row scrolling effect ) Now I want to apply that to a word like CHAR that expects 4 cells of that to be on the stack. I can see how I can use the address and loop over the range I want to select, and stuff those onto the stack. But I imagined that I would capture the stack address, grow the stack, and then perform a MOVE into that stack space. The only way I can see to manually grow the stack is by manipulating the stack pointer register, but that seems wrong as I'm reaching into the implementation of the language. Or is that the idiomatic way in forths? [email protected]

I had another interesting idea, I expect everyone has thought of before, but with carts like the ubergrom, fbForth could be in the eeprom, and what if there was a bit in the rom that could be set so it would bload a range of blocks from GROM in the ubergrom atmega chip? I'm not (hopefully) proposing any major change in structure to fbForth. It could continue to own the ROM and ROM banking. The ubergrom seems like nice development aid. Given that it has GRAM space that could be used during development, something like having GSAVE tools on the fblocks tool set that would be like a BSAVE to GRAM, to test with. I haven't thought this through too deeply, but large things could be built using BSAVE swapping techniques Lee outlined in the fbForth manual, and all loaded fast off of cartridge. I imagine the GRAM space would be handy during development, but the GROM space would make more sense to solidify the code into. The GRAM could be useful for an individual app too. I suppose something similar could be done from from extended banks on the ROM side itself, but I imagine that is complicated by the bank switching already in fbForth. I imagine the only change required to fbForth would be a setting in the rom that can be set indicating to bload block 1 or a range of blocks from a grom address instead of from disk. Then the loaded block(s) can take control. ( maybe bload for block 1 isn't right, cause you problably want to execute some word(s) automatically. ) But hopefully I've communicated the concept. Just an idea. [email protected]

Nice! I get now. If I'm using your fblocks, I just don't worry about it. If I'm creating an standalone blocks file, and I have have the font block in block #5, I don't have to do anything... If I want the font block in block #2 or something, I just set the user variable in block #1, then set my graphics mode like I already do and away we go. If I don't want the runtime cost of loading from disk, (maybe I change graphics modes frequently) I just set the user variable to block #1 ( not a font block ) and we'll get the console font when changing graphics modes. In development workflow, where I switch between the editor in text80, and mode 2 graphics, it might be nice to be able to effectively disable the behavior of FNT, maybe if the user variable can be set to indicate no font change, or explicitly set to load console font, behavior can be more deliberate. The last one doesn't eliminate the need to fallback if a valid block number is specified. Just offering an idea: maybe -1 is disables the behavior of FNT, and 0 explicitly loads the console font, and any other value attempts to load from the block file, falling back on console font if the block isn't a font block. [email protected]

A user variable wouldn't be set until after getting into block #1 so I'm not sure how that would be used. A word that loads the font from a specified block, would be just as easy to call. Would that user variable be preserved through a cold or something? Or used during the call to graphics or text? I like the idea of checking the block for a header as a little validation. [email protected]

That is a seriously good alternative

Yep, that fixed it. New source pushed to github, and new binary firmware up on my downloads page. Thanks Tim, for chiming in, that I shouldn't expect this behavior. I sort of assumed it was like old PCs in the past that would halt in BIOS startup if the keyboard test failed. Now I can switch the keyboard all I want, even when booting the Geneve... worry free. I love it! [email protected]

In case it is useful for others, (or my future self) here is a screen shot of how the minipro TL866 software looks with all the check boxes set for programming the 'config' or fuses. Notice the config button on the right is depressed. That wasn't obvious to me for a while And you can double check the hex bytes that will be programmed in the square I have highlighted. I needed to upgrade the MiniPro Programmer software before it would program the atmega config properly. With the previous version of the burner software that I had, it always failed validation on the config bytes. [email protected]

It appeared to. I skipped the IO pin testing, but they appeared to have reasonable disconnected values. And then everything buttoned up when it was finished. Thanks! [email protected]

Those instructions where great, they translated nicely to the minipro programmer. I fetched the archive off of harmlesslion, and loaded it onto the chip, and I was greeted by the test program that isn't supposed to be there anymore. Is it still not supposed to be there anymore? Did I snag an outdated hex file? Changes inside the archive are dated 6/2/2015. Or was the test program beneficial enough that it was brought back? [email protected]

Interesting, well, I haven't tested with absolutely no keyboard attached, but when no keyboard is attached to my USB adapter. After loading the last track of System/Sys, the floppy drive access ends, and the screen just stays there on the Loading MDOS... image. It is very consistent. Maybe the Geneve thinks a keyboard is present since a device is attached to the XT keyboard, and attempts the keyboard reset, but my adapter won't ack the reset. I'll experiment with leaving the XT data lines disconnected until after the USB keyboard is detected. Maybe that'll fix'er. [email protected]

This is pretty awesome software. I use Avast antivirus, and it went a little nuts on the magellen.exe and quarantined it. Running straight from the jar works fine. [email protected]

I just unraveled the mystery as to why my Geneve sometimes hangs during bootup, and turns out it disapproves of there being no keyboard connected when kicking off MDOS. So be warned if using the Geneve firmware and a KVM or USB switch. [email protected]

Statements like that make me curious about the history of the term Fest West. This thread mentioned a few prior venues. I've seen some historical mention of Fest West and Tucson. When I was in high school, I came down from the Seattle area to go to a TI gathering in Portland, OR. I don't remember if that was called a Fest West. Later I think the Queen Anne computer group in Seattle held a 'swap meet'. Now I'm rummaging around in parts of my brain that have been happily idle for decades... I picked up a CC-40 at that Seattle event, and a Gram Karte. That CC-40 was my first 'PDA' if you will. Anyway... Those probably happened somewhere between 1986-89. I wonder if anyone has significant histories around previous 'Fest West' they'd like to share? [email protected]