Supporting the TRS80 Model II
Supporting the TRS80 Model II
The list of the supported CP/M disk formats is now rather complete (CP/M Plus still missing), and I'm trying to enrich the library of this nice dinosaur.
I managed to page in the VRAM on the TRS80 model II, but ATM it works only with a single CP/M version, the P&T.
Trying to squeeze out some graphics, I'm now in one of those challenges
..I guess an 80x72 pseudo-pixels rez is the most we can get
I managed to page in the VRAM on the TRS80 model II, but ATM it works only with a single CP/M version, the P&T.
Trying to squeeze out some graphics, I'm now in one of those challenges
..I guess an 80x72 pseudo-pixels rez is the most we can get
You do not have the required permissions to view the files attached to this post.
Re: Supporting the TRS80 Model II
It can be easily fixed to work also on low memory systems, but the memory banking on all the OS versions is an issue.
You do not have the required permissions to view the files attached to this post.
Re: Supporting the TRS80 Model II
I managed to page the VRAM properly.
All the CP/M versions use bank 1, thus outputting $81 and $01 to port $FF seems to suffice.
In theory it might affect the timers but works
All the CP/M versions use bank 1, thus outputting $81 and $01 to port $FF seems to suffice.
In theory it might affect the timers but works
Re: Supporting the TRS80 Model II
When trying to compile like this...
zcc +cpm -subtype=ptcpm -lgfxtrs80m2 ......
...with the current nightly, it says:
error: file open: gfxtrs80m2.lib
That library seems to be missing.
zcc +cpm -subtype=ptcpm -lgfxtrs80m2 ......
...with the current nightly, it says:
error: file open: gfxtrs80m2.lib
That library seems to be missing.
Re: Supporting the TRS80 Model II
I *think* it will be built tonight
Re: Supporting the TRS80 Model II
No success yet, there is only gfxtrs80.lib in the nightly package.
Re: Supporting the TRS80 Model II
Er, it's not been merged yet: https://github.com/z88dk/z88dk/pull/2299
Re: Supporting the TRS80 Model II
ok.
Tomorrow morning, then !
Tomorrow morning, then !
Re: Supporting the TRS80 Model II
Thanks, now it's there and working!
Mono sprites perform very well in 80x72.
Another issue: can you get the virtual joysticks to work in CP/M?
They are supported on the TRS-80 Model 1 in native mode.
Compiling joytest.c for Model 2 CP/M results in these errors:
Mono sprites perform very well in 80x72.
Another issue: can you get the virtual joysticks to work in CP/M?
They are supported on the TRS-80 Model 1 in native mode.
Compiling joytest.c for Model 2 CP/M results in these errors:
Code: Select all
joystick_inkey.asm:16: error: undefined symbol: keys_qaop
^---- keys_qaop
joystick_inkey.asm:19: error: undefined symbol: keys_8246
^---- keys_8246
joystick_inkey.asm:22: error: undefined symbol: keys_vi
^---- keys_vi
joystick_inkey.asm:25: error: undefined symbol: keys_cursor
^---- keys_cursor
joystick_sc.asm:37: error: undefined symbol: in_KeyPressed
^---- in_KeyPressed
You do not have the required permissions to view the files attached to this post.
Re: Supporting the TRS80 Model II
There's a but of target specific I could add, eg timer. You might try the same library in trsdos mode , in the meanwhile
Edit: -subtype=cmd
Edit: -subtype=cmd
Re: Supporting the TRS80 Model II
Oh, the .cmd file works with the model II as well, that makes life easier.
However, when running grtest from the .cmd file, there is no text output:
When running it from Lifeboat CP/M, text output is there:
My compile commands look like this:
zcc +trs80 -lndos -lgfxtrs80m2 -create-app -o grtest_trs80_m2_LowRes.bin -subtype=cmd grtest.c -D__TRS80M2__
zcc +cpm -subtype=lifeboat -lgfxtrs80m2 -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -o GT.COM grtest.c -D__TRS80M2__
However, when running grtest from the .cmd file, there is no text output:
When running it from Lifeboat CP/M, text output is there:
My compile commands look like this:
zcc +trs80 -lndos -lgfxtrs80m2 -create-app -o grtest_trs80_m2_LowRes.bin -subtype=cmd grtest.c -D__TRS80M2__
zcc +cpm -subtype=lifeboat -lgfxtrs80m2 -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -o GT.COM grtest.c -D__TRS80M2__
You do not have the required permissions to view the files attached to this post.
Re: Supporting the TRS80 Model II
Try avoiding the generic console support (not implemented yet). The native mode could work.
"-pragma-redirect:fputc_cons=fputc_cons_native"
"-pragma-redirect:fputc_cons=fputc_cons_native"
Re: Supporting the TRS80 Model II
I read the few documents I could find, it probably won't work.
MODEL II and 4 had different architectures and different ROM entries.
Possibly the model I could be emulated, but I'm avoiding to focus on a limited configuration just to work around the current issues.
I pulled in also the Model 4 160x72 mode (-lgfxtrs80m4), but any attempt to use any of the existing I/O console functions will either crash (in TRS80 mode, due to different ROM entries) or destroy the picture by entering in full text mode (CP/M mode).
The graphics library itself looks nice, though (you can run coswawe.c or other gfx output only stuff).
MODEL II and 4 had different architectures and different ROM entries.
Possibly the model I could be emulated, but I'm avoiding to focus on a limited configuration just to work around the current issues.
I pulled in also the Model 4 160x72 mode (-lgfxtrs80m4), but any attempt to use any of the existing I/O console functions will either crash (in TRS80 mode, due to different ROM entries) or destroy the picture by entering in full text mode (CP/M mode).
The graphics library itself looks nice, though (you can run coswawe.c or other gfx output only stuff).
Re: Supporting the TRS80 Model II
Considering the many different HW and SW architectures sharing the same brand name of TRS-80 I think we need to find the best compromise.
"fputc_cons_generic" in CP/M mode surprisingly runs fine on many CP/M versions of the TRS80 Model 4 and Model II but fails on P&T and FMG CP/M for the Model II and possibly others.
I'm wondering if and how to deal with direct hardware control for the console I/O on those 2 models. I put the target specific paging code (and base_graphics alteration) in swapgfxbk_m2.asm and swapgfxbk_m4.asm, but I probably need it also for stdio... Now I'm understanding why Dom decided to merge console and graphics, elsewhere !
By the way, since on Model 4 any call to BDOS restores the non-graphics font, I first need to learn how to decode the keyboard, first. Probably t's not happening soon.
"fputc_cons_generic" in CP/M mode surprisingly runs fine on many CP/M versions of the TRS80 Model 4 and Model II but fails on P&T and FMG CP/M for the Model II and possibly others.
I'm wondering if and how to deal with direct hardware control for the console I/O on those 2 models. I put the target specific paging code (and base_graphics alteration) in swapgfxbk_m2.asm and swapgfxbk_m4.asm, but I probably need it also for stdio... Now I'm understanding why Dom decided to merge console and graphics, elsewhere !
By the way, since on Model 4 any call to BDOS restores the non-graphics font, I first need to learn how to decode the keyboard, first. Probably t's not happening soon.
Re: Supporting the TRS80 Model II
Long story short: the fallback code to emulate the joystick is now in, for the nightly build.
Re: Supporting the TRS80 Model II
I'd recommend you do the same as I did with the Super80 - split into two different -clib options to handle the differences in ROM entry points. There's fundamental differences in the hardware and ROM to justify it and it just makes life easier.
Re: Supporting the TRS80 Model II
Thanks, Deepspace is now working in CP/M mode (albeit very blocky in 80x72, but surprisingly fast).
QAOP-NM and 8246-05 work fine, Cursor and hjkl-sd currently do not (no reaction).
Two more issues:
- Can you disable the blinking cursor?
- 1-Bit sound should be supported and available "out of the box" on the Model II (without any hardware expansion)? According to __HAVE_ONEBITSOUND it is not available, and my 1Bit.c test hangs when trying to play the first sound.
Attached are the WIP source files for testing.
You do not have the required permissions to view the files attached to this post.
Re: Supporting the TRS80 Model II
I fixed the cursor issue when in graphics mode, I'm pulling the change today.
The sound is not present, actually the Model II does not have a tape interface.
I wrongly assumed the audio output trick evolved to a sort of standard because it was widely used, this is an abstract from the Service Manual for the model 4P:
5.1.13 Sound
The sound circuit in the Model4P is compatible with the Sound
Board which was optional in the Model 4. Sound is generated
by alternately selling and clearing data bif DO during an OUT to
port 90H. The stafe of DO is latched by U130 (1/2 of a 74LS74)
and the output is amplified by 02 which drives a piezoelectric
sound transducer. The speed of the software loop determines
the frequency, and thus, the pitch of the resulting tone. Since
the Model 4P does not have a cassette circuit, some existing
software that used the cassette output for sound would have
been lost. The Model 4P routes the cassette latch to the sound
board through U142. When the CASSMOTORON signal is a
logic low, the cassette motor is off, then the cassette output is
sent to the sound circuit.
The sound is not present, actually the Model II does not have a tape interface.
I wrongly assumed the audio output trick evolved to a sort of standard because it was widely used, this is an abstract from the Service Manual for the model 4P:
5.1.13 Sound
The sound circuit in the Model4P is compatible with the Sound
Board which was optional in the Model 4. Sound is generated
by alternately selling and clearing data bif DO during an OUT to
port 90H. The stafe of DO is latched by U130 (1/2 of a 74LS74)
and the output is amplified by 02 which drives a piezoelectric
sound transducer. The speed of the software loop determines
the frequency, and thus, the pitch of the resulting tone. Since
the Model 4P does not have a cassette circuit, some existing
software that used the cassette output for sound would have
been lost. The Model 4P routes the cassette latch to the sound
board through U142. When the CASSMOTORON signal is a
logic low, the cassette motor is off, then the cassette output is
sent to the sound circuit.
Re: Supporting the TRS80 Model II
I'm afraid I'm stuck.
Dom, how should I get the obj files built in the proper position for the mc6845 part ?
https://github.com/z88dk/z88dk/pull/2348
Dom, how should I get the obj files built in the proper position for the mc6845 part ?
Code: Select all
(...)
zcc +trs80 -O2 -vn -c -o obj/trs80m2/xorplot.o xorplot.asm -Ca-I../.. -Ca-DFORtrs80m2
zcc +trs80 -O2 -vn -c -o obj/trs80m2/xorplot_callee.o xorplot_callee.asm -Ca-I../.. -Ca-DFORtrs80m2
TARGET=trs80m2 TYPE=z80 z88dk-z80asm -d -I/home/runner/work/z88dk/z88dk/lib/config//../ -DFORtrs80m2 -x/home/runner/work/z88dk/z88dk/libsrc//gfxtrs80m2 @/home/runner/work/z88dk/z88dk/libsrc//../libsrc//target/trs80/gfxtrs80m2.lst
video/mc6845/mc6845.lst:1: error: file not found: video/mc6845/obj/trs80m2/asm_set_cursor_state
^---- video/mc6845/obj/${TARGET}/asm_set_cursor_state
make: *** [Makefile:1752: gfxtrs80m2.lib] Error 1
make: Leaving directory '/home/runner/work/z88dk/z88dk/libsrc'
Error: Process completed with exit code 2.
Re: Supporting the TRS80 Model II
Thank you Dominic
RobertK, the fixes should now be in.
RobertK, the fixes should now be in.