jedimatt42
-
Content Count
3,431 -
Joined
-
Last visited
-
Days Won
3
Posts posted by jedimatt42
-
-
I will definitely post it later today. Right now I am at the first birthday of our youngest grandson (# 20!).
Congratulations!
And looking forward to it. But of course, no rush. Enjoy the family time.
-
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.
-
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-dI don't know the quality of that though.
-
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.
-
1
-
-
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.
-
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.
-
1
-
-
now having arcadeshopperdotcom on facebook suddenly makes sense to me
-
2
-
-
FYI, here is how CHAR was written by TI programmers:
...
And—here is how I translated that to ALC:
...
As you can see, it was first necessary to pop the pattern data from the stack to a temporary location (fbForth’s PAD 68 bytes above HERE , not scratchpad RAM at 8300h) before using VMBW .
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.
Re refining the manual, I intend to do that; but, first I plan to write an addendum that details the changes since the last update of the manual so folks who have already printed the manual won’t need to reprint the whole thing. I hope you are making notes that I can call on when I get around to the rewrite.
Yes, an addendum would be great. Regarding tweaks to the manual... I'll try to preserve some notes.
That I gotta see! Did you write and install your own ISR per Chapter 10?
...lee
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.
-
1
-
-
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
) -
1
-
-
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?
-
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.
-
Actually, a user variable that is defined in the kernel (which is how I would do it) usually has a default value assigned before ever loading a block. I will set it up like the VDP mode colors to survive COLD .
FNT is called for every change in VDP mode so, yes, this particular user variable would get used.
...lee
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.
-
We’re on the same wavelength this week! I was just going through code to see where I could rearrange things to make room in bank 0 for the additional code fields and parameter fields I will need.
Once I free up enough space, I need to work out the best way to manage the default font.
If I expect it to be in the current blocks file in, say, block #5, it would need to be in block #5 in every blocks file the user invokes—much as the requirement in TI Forth for system messages to be in blocks #4 and $5 for any disk in DSK1. I don’t like to hardwire block numbers into ROM code (except for block #1), so I would probably set up a user variable for this purpose. Because I don’t need the first 256 bytes of the current default font, I could set up a validation code at the start of the block and fail over to the console font if is not found.
Or—I could use a default font file on the boot disk—DEF_FONT, or some such.
Or—?
...lee
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.
-
I am thinking seriously of putting the default font in a block in FBLOCKS. If I go that route, I will, upon failure to find FBLOCKS, load the console font with its small caps for lowercase as shown here
...lee
That is a seriously good alternative
-
1
-
-
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.
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! -
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.
-
2
-
-
Did the test program actually work?
No big deal... I didn't think I shipped the whole package anymore.
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!
-
There are only two things you need to do to turn an AVR into an UberGROM. (After that, use it on the board in the TI and stop thinking of it as an AVR, it's a product at that point.
). You can and should load software with GROMCFG, or even the standalone loader GROMLOAD, unless you know better - that tool is meant to make it easier to distribute and load finished images. People are free to distribute the standalone loading tool with their products.Those instructions where great, they translated nicely to the minipro programmer.
A quick technical note, skip if not interested in the technical parts - on startup the AVR code checks if the configuration area in EEPROM is blank, which it will be in this case. When it finds this, it does a basic initial configuration. This initial configuration was designed to activate a test program, but that test program isn't loaded anymore, so you'll just see a basic configuration in GROMCFG when you get there. Thus it is fine to not load any EEPROM data on a fresh chip.
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?
-
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.
-
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.
-
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.
-
I'll be sending Omega a DIY surprise prize for the Fest as well. . .something very appropriate to a Fest West.
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?
-
Firmware with updates for the CTRL-SHIFT issue and the other issue are up on the website:
http://ti994a.cwfk.net/Downloads.html
Once upon a time, my adapter worked quite well with Micro Pinball II, using the 1, 0, and = keys. But that broke a while back. I'm not sure when, but I suspect it broke when I made some other things more correct. Given that the Rave adapter I had as a kid didn't work with Micro Pinball II either ( I had to use the 1 for left flipper, and N for both flippers back then as well. ) I'm going to let that rest for a while.
-
Yea. I probably don't even need to set the row and column each time through the loop. However, I have been playing with some re-entrant interrupt-driven keyboard routines, and am trying to retain my sanity while testing.
I have been able to make my keyboard adapter work with it, but then I noticed another unrelated issue I want to fix today. It wasn't as straight forward to fix the ctrl-shift release feature as I had hoped. It turns out the USB input communication dominates the processing power in the Teensy, unless I use interrupts to handle the TI scans. But I was able to add a little logic so that if no interrupt has been handled in a very brief amount of time, then update the output rows anyway. This did allow me to stop special casing F4 to break out of the TI BASIC program : 10 GOTO 10 and F=, releasing during RESET. They work and release naturally now. I'm not sure how F4 can be read without scanning multiple columns. I don't actually think that is possible, but this same change solved that. I'll take the cleaner code.
The new bug I found is an issue with contractions that causes things like didn'] if you type fast. I had fixed this in one of my early iterations, but have thoroughly revamped since then, and need to re-fix it. Tursi warned me of this early on
It can cause you trouble when backspacing and arrowing around as well. These issues are all mechanically possible on the stock 4a keyboard, but unnatural and awkward, so they didn't happen. ( I am glad the Geneve has all of this challenging stuff built into it, and just takes serial XT scan codes... that adapter was a piece of cake by comparison. )
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
PNW - TI-99/4A Fest West 2016 - April 30th
in TI-99/4A Computers
Posted
That is awesome to see!