Open patricksurry opened 8 months ago
That's an interesting thought. I don't think I've had any users that were short on RAM - usually it's the ROM size that people want smaller. Because Tali only targets the 65C02, you don't see people trying to use it on old systems with 8K or less of RAM (Tali runs quite comfortably with only 8K of RAM). Even though Tali trades code size for speed with its native compiling, it still generates code that is quite compact for the functionality you get.
I agree it's possible, and I think it's a neat idea, but I don't know as it makes sense to put in the effort for something that may not be useful. That's the kind of customization that someone could do on their own fork of Tali if it makes sense for their platform. I'd also like the configuration options for Tali to be as simple as possible for new users. Many have never touched 65C02 assembly before, but are looking for something more powerful than BASIC.
You had mentioned you use ca65 as well. That was one of the other contenders when we were looking for a new assembler that supported conditional assembly, but we decided that the creation of an ld65 configuration file was too high of a bar for many new Tali users.
ya, that's a fair point.
I suspect a great way to introduce people to Tali would be to put together a ben eater cheat sheet/tutorial so you could write a prebuilt rom with his default IO handlers to your eeprom and just use it on your tiny lcd; along with some simple "how to" for actually compiling and customizing it. there's such a big reddit community around it
That's not a bad idea - about the time they get the serial port working would be a good time for Tali and writing up some LCD routines would be pretty simple. I know of at least one user that was trying to get Tali working on a ben eater styled machine.
Tali works best with hardware handshaking (no inter-line delays needed when copying code over the serial link), but that may not be that difficult to add (hardware-wise) for folks who are still working on a breadboard. The ACIA already supports it and just needs it wired to the serial (or USB to serial) port. The code for a WDC 65C51 also works for other brands (it needs to use a delay when transmitting characters as the TX_EMPTY flag is stuck (design defect on WDCs parts only, which is why I use Rockwell parts instead)). An alternative would be to recommend terminal software that can add the inter-line delays (Tali doesn't normally need inter-char delays like FIG-FORTH or BASIC sometimes do).
A walkthrough of coding for the LCD screen (in Forth) might also make a good tutorial. Once you understand basically how the LCD screen works, it's easy to see how the problem gets broken down into words for sending data and sending commands to the screen and then those can be used to send strings to the screen.
ya, this is how i got back into 6502 world actually. i used to code a real apple //e many years ago, and got hooked into the breadboard build videos which obviously i went overboard with. the assembly itself is enjoyable but forth seems a much more useful but still close-to-metal way to work on the resulting setup, and would be a lot less frustrating than the code/compile/burn eeprom/debug/repeat loop.
On Wed, Mar 27, 2024 at 3:40 PM SamCoVT @.***> wrote:
That's not a bad idea - about the time they get the serial port working would be a good time for Tali and writing up some LCD routines would be pretty simple. I know of at least one user that was trying to get Tali working on a ben eater styled machine.
Tali works best with hardware handshaking (no inter-line delays needed when copying code over the serial link), but that may not be that difficult to add (hardware-wise) for folks who are still working on a breadboard. The ACIA already supports it and just needs it wired to the serial (or USB to serial) port. The code for a WDC 65C51 also works for other brands (it needs to use a delay when transmitting characters as the TX_EMPTY flag is stuck (design defect on WDCs parts only, which is why I use Rockwell parts instead)). An alternative would be to recommend terminal software that can add the inter-line delays (Tali doesn't normally need inter-char delays like FIG-FORTH or BASIC sometimes do).
A walkthrough of coding for the LCD screen (in Forth) might also make a good tutorial. Once you understand basically how the LCD screen works, it's easy to see how the problem gets broken down into words for sending data and sending commands to the screen and then those can be used to send strings to the screen.
— Reply to this email directly, view it on GitHub https://github.com/SamCoVT/TaliForth2/issues/57#issuecomment-2023825919, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABA5MKTH4GHLXBA3YEF7BYDY2MOCJAVCNFSM6AAAAABFK3G2M2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTHAZDKOJRHE . You are receiving this because you authored the thread.Message ID: @.***>
the original title of this issue is moot now that we're using that space for loop stack. but maybe rename this to suggest a beneater-compatible build/tutorial?
I think it makes sense to add a beneater platform file for those who are using the "standard" beneater decoding logic. A tutorial using the LCD could use specific beneater addresses, but would be usable for anyone with an LCD wired to a VIA in the same manner by just changing the addresses.
beneater's wozmon port shows IO interaction via serial port:
init
ACIA_DATA = $5000
ACIA_STATUS = $5001
ACIA_CMD = $5002
ACIA_CTRL = $5003
RESET:
LDA #$1F ; 8-N-1, 19200 baud.
STA ACIA_CTRL
LDA #$0B ; No parity, no echo, no interrupts.
STA ACIA_CMD
get a key:
NEXTCHAR:
LDA ACIA_STATUS ; Check status.
AND #$08 ; Key ready?
BEQ NEXTCHAR ; Loop until ready.
LDA ACIA_DATA ; Load character. B7 will be '0'.
show a chr:
STA ACIA_DATA ; Output character.
LDA #$FF ; Initialize delay loop.
TXDELAY: DEC ; Decrement A.
BNE TXDELAY ; Until A gets to 0.
or his VIA-based LCD setup for hello-world, just jsr print_char
with his VIA-based keyboard interface
Otherwise it's a standard setup with 4K of RAM (0-3fff), and 32K of ROM (8000-ffff).
refactoring the zp/user cold start tables made me realize (a) would be nice to conditionally remove vars tied to optional features to increase forth stack space, and (b) minimal config could move
up
down to $100, using first few bytes of cpu stack which are rarely used and freeing another page for system use