Tursi
-
Content Count
7,205 -
Joined
-
Last visited
-
Days Won
8
Posts posted by Tursi
-
-
Can someone show me exactly what they see on the emulator that's wrong?
As I noted, I can't reproduce it. My real TI shows the same results as Classic99 does.
If you are running a older version of Classic99 that doesn't have the joystick lockout feature, of course, all bets are off. It affects the keyboard because you are pressing a keyboard key. Use a real joystick to avoid the problem there (or turn off the PS/2 extension in Classic99.ini).
-
Looks amazing.. plays very well too!
I can't reproduce your key issues here, though.. from looking at your code, I'm assuming you were seeing problems with the sprite changing pattern, but it seemed to work correctly here.
-
This is my test program (similar to Sometimes):
10 CALL JOYST(1,X,Y) 20 CALL KEY(0,K,S) 30 PRINT X;Y;K;S 40 GOTO 10
I can't make the joystick (X and Y) affect the keyboard output (K and S) with Joystick 1 configured as keyboard.
Perhaps you can tell me what version of Classic99 you have (to be sure) and what you actually see in your test program?
This is the way it is supposed to work:
Normally, the arrow keys map to FCTN E/S/D/X, and Tab maps to FCTN-7. However, when you scan the joystick pin, if they joystick is configured to use the keyboard, Classic99 turns those keys off and dedicates them to the joystick for 2-3 seconds. Thus, if a program keeps scanning the joystick, they should not respond as keys. But if a program stops scanning the joystick, they revert back to keyboard use again. This does not happen if you are using a real PC joystick instead.
That functionality is relatively new, so maybe it's broken. But in TI BASIC that test program appears to do the right thing for me?
Hmm... in studying it a bit closer, though, I do see different behavior in the S variable return when joysticks are included as when they are not. K appears to always be correct, and moving the joystick seems to have no impact, but S doesn't behave the same way. It should be 0 when no key is pressed (always true), 1 when a key is first pressed, and -1 if the same key is pressed as last call. The 1 and -1 don't behave predictably if the CALL JOYST is in the loop.
This seems unlikely to be a Classic99 bug, though.. has anyone tried it on the real hardware? I'm at work at the moment and they still haven't let me set up a 4A in my cube.
Maybe you've found a KSCAN bug... -
Trackers are not so intimidating once you get used to them... a bit like programming.
I never had any talent but I used to fix up broken MODs back in the day with new instruments, even added a note here and there. The segment stuff - I admit I've never read the E/A manual section on them... this is just taken from all the other systems I've worked with. (My bank switched work on other systems would never have happened without the ability to define custom segments, actually).
The idea with different segment types is to solve exactly the problem we're talking about here - where program needs to go in one place, and data in another. You can do something like this:
DSEG score BSS 2 score2 BSS 2 high BSS 2 level BSS 2 PSEG start LIMI 0 ... etc code here
Then when you link it, you tell the linker that the DSEG goes at >8300, or >2000, or whereever your RAM is, and the PSEG goes at >A000, or >6000, or whereever you want the code.
In a new assembler, custom segments would be preferable to the ones TI defined (maybe keeping with the more common default of the 'text' segment being program, 'data' being initialized data, and 'bss' being uninitialized data, with the ability to add your own, something like "SEGMENT text" as the directive).
Then for things like our multi-bank cartridges, you could have segments named BANK1, BANK2, BANK3, etc. You set them all to the same address in memory (>6000), and then all your labels and such line up, but the linker can still figure out where to put each block of code.
When building to RAM, usually the segments all just get packed together, the main advantage there is that the linker works out exactly where everything needs to go, rather than needing to define the blocks.
-
I wish THE Doctor, hehe.
Hehe.. if you just want the synth to speak crap, just send it a broken LPC string, probably don't even need SPGET.
-
Yup, I found that tracker last night and messed around with it a little. Very clunky and hard to use IMHO. I don't know what he used to write that with, but a language that would have allowed him an easier and more standard interface would have been a better choice, again IMHO. Either way, it is better than nothing and lets me mess with the sounds quickly and with reasonable feedback. A few of the sounds are pretty nice, however the best sounding one seems to use a frequency setting of 1/2 of the real Master System, so those sounds would not be possible on the real gear (lower frequency for better sounding bass tones.) I wonder if the SMS uses the same frequency as the 99/4A?Yes, it does. So does the Colecovision and (though the chip is a little more advanced) the MSX.
It's actually pretty standard for trackers to use their own GUIs, I guess you never messed around with MOD files. Doesn't make it any easier to get the hang of, but the point of the interface isn't loading and saving files, but composing music. To that end it functions like most traditional trackers. I'd say it's substantially better than nothing.
The ability to import VGM and export in the somewhat size-reduced EPSGMOD format is actually a benefit if you want to use tracks from other systems - there are thousands of VGM files recorded from almost every game released on SMS (and Genesis, but you won't get much out of those files). The downside is VGM is fairly wasteful of space, since it records every change sent to the sound chip (meaning, for instance, a bell sound has every volume change recorded, while the native format would only need a single note). The MOD and MIDI imports are also disappointing, the resulting files are nearly useless most of the time. I had planned to write my own converter for them at some point as I have some files I need to convert, and I want very simple changes (like storing drums only on the noise channel, not whatever happens to fall there...
). Again, dunno when or if that will happen. The music composition itself is quite good, though, offering a lot of variety in the sounds produced. It has full control over the noise channel, better-than-ADSR keying on the waveforms, and vibrato and modulo for free. Most importantly, a working tracker is not a simple thing to build, plus it apparently supports MIDI input, suggesting that you can compose your tunes with a MIDI keyboard.
-
Ah, I see. kind of like an ENUM in C. That would be nice to have, maybe I'll do something like that in my assembler (if I quite writing games long enough to finish it.) A construct that lets you designate a start address, then simply indicate how many bytes each label should represent. hmm.
Actually, Matthew, if you just support segments (using the TI naming scheme or something else), that's really what they are for. The idea of segments is just that each segment has its own address counter, and you switch between segments freely in your code. Then when you assemble or link, that's when you tell the computer what address to base each segment at. This makes it easy to write code that works both in RAM and on cart, you just change the data segment and program segment addresses around.
-
I would really like a way, without using file I/O, to save the high score table. A nice battery backed RAM would be nice. :-) Maybe I could talk Tursi into letting me write to the ROM addresses (I spent a good hour early on in the development trying to figure out why my variable values were not changing. This is my first ROM based code so *usually* you can change your DATA and BYTE variables when your code is loaded into the low or high memory expansion.) If I could write to the ROM addresses then at least in the emulator the high scores could be saved. Also, as for the a real cartridge, I'm making mine with this neat chip I have from Dallas Semiconductor, a DS1225AD which is a RAM chip that has the pinout of a ROM, but also has a 10-year battery built in. They call it a Nonvolatile SRAM. It is much easier to work with than a real EPROM because erasing is simple (no UV or anything like that), and I can write to it in circuit if I want. They are not too expensive and I actually got mine as a free sample from Maxim-IC. :-)I could probably add a new ROM image type for that once it's proven to work on hardware.
The concept is simple enough.. just have to make sure there's no extra hardware required that would affect emulation. -
hehe... definately.
But there's a practical reason, too. Some modern systems (like my old projector, grr) can't handle the 262 line progressive scan signal the TI, and other classic systems of the day, outputs. Specifically in my case, the bottom half or so of the screen would jump and flicker badly. This happened with my Atari 2600, ColecoVision, Genesis and TI. So a more modern output video signal keeps the machines running on modern displays. Just not sure which approach I'll take. Since my solution is reasonably years out yet, not much point planning in too much detail.
-
Any reviews pending of Mario?
The shipping issues kind of overshadowed any talk about the game. -
Any chance of an HDMI cable for the TI?
Yes there is, actually...
But it's way, way, way down on my massive TODO list. :/
-
It looks fantastic!
Remember that when speaking in XB, your program is essentially hung, it can't do anything else.
As for the rest of the problems with speech.. slowly.
Will get there eventually. Speech wouldn't be implemented in the half-assed way that it is at all if a certain 'Doctor' on the old TI list hadn't gone on a rant one day. -
These are also supported by the assembler, but the EA Loader won't accept them. You have to write a custom loader yourself:CSEG - Common Segment
CEND - Common Segment End
DSEG - Data Segment
DEND - Data Segment End
Like I said, most 99'ers have never bothered to investigate these because the system isn't that great for segmented architecture. Nearly every TI application is converted to memory-image absolute files that are just chain-loaded into memory. Often referred to as 'E/A Option 5'.
Well.. that, and the fact that the loader doesn't support any of the segments except the program segment, which is the default anyway.
Having actual segment support would be nice for some instances - like building ROMs.
-
I always thought the Q key was hard wired to the fire button, and think, all along it was clever programmers.Now you've forced me to go look up which is the answer.
Columns 6 and 7 uniquely scan the joysticks, and no keyboard rows, so it is possible to read the joystick distinct from the keyboard. However, KSCAN unit 1 and 2 reads both 1/2 the keyboard AND the associated joystick fire button. The fire button returns a code of '18', which matches Q on joystick 1 and Y on joystick 2.
KSCAN is a little bit complex, but some interesting points. If fire is pressed, the keyboard unit scan is skipped (mode 1 and 2, that is), so the joystick can override the keyboard. The same indexing code is used to get the final return value as for keyboard scan. So any app that calls KSCAN will be unable to distinguish the fire button from Q/Y.
Is it really documented in the txt file? I did read it, at least once.Two places even. Under the keyboard section:
The arrow keys normally return FCTN+E/S/D/X. If joystick emulation is set tokeyboard, and the program scans the joystick, then these keys (and Tab) respond
to the joystick request only. After about 3 seconds if the joystick is not
scanned again, they return to being keyboard keys.
And under the configuration reference, joystick:
joy1mode (and joy2mode for joystick 2)0 Keyboard (arrow keys and tab)
1 PC Joystick 1
2 PC Joystick 2
Moving on...
Trackers are typically for arranging tunes by stringing along byte values, sometimes graphically and sometimes manually. There are a lot of good ones for the C64 but I don't know of a TI one.I ported the ePSGMod format to the TI... my code is here: http://harmlesslion.com/software/psgmod
The original tracker is here: http://www.kontechs.de/product?name=mod2psg2
And the sample program is built into Classic99 under Cartridge->Apps->EPSGMOD Sample
SPECTRA has also built the player in.
However... the author hasn't supported the tracker well.. he gave me the 2.05 code years ago and still hasn't updated the tracker itself on his site. That, plus the license terms, has me thinking we might want to just roll our own. The attraction of this tracker was the ability to cross-pollinate with the Master System crowd (and hell, Coleco and MSX can use it too), but it doesn't seem to be heavily used. Besides Shiru's (amazing) tracks, I've seen very little else.
-
Had a quick play here at work... looking good! Very nice with a fast response time like that.
Getting wrapped up by the spider is oddly creepy...
-
Argh, what's the keyboard equivalent for the fire button in Classic99? Never seems to be the same key twice.
It's been Tab consistently for 15 years now.
Note that in most games, "Q" also responds for Joystick 1, and some games map an alternate key (like period) as fire, but this isn't Classic99's fault. If you are using the keyboard for joystick emulation, it's arrow keys and tab.
It's not configurable today.This is documented in Classic99.txt. I know you guys bitched me out about my docs but "pretty" ones are coming, then there will be no excuses.
-
-
Even doing that does not solve the problem. When the lines of FlyGuys are being erased, the "proper" thing to do would be to restore what was under them to begin with. Having a second screen does not help with that. Since I don't have the RAM in the console to store the 54 characters I need (I can't use the 32K expansion since I'm trying to keep this as a console cartridge that will run on an unexpanded system), I'd have to copy in chunks from the VDP into a small buffer in CPU RAM, then back into VDP RAM. Then when erasing the FlyGuys, I'd have double the VDP accesses to get the original characters from VDP RAM and put them back in their original location in VDP RAM. I know what to do, I just need to do it. But I didn't want to spend that much time on it if the effect was lame or confusing to the player.You say you have it already, but as a suggestion.. when you have tons of ROM and little RAM, use the ROM. It might be helpful to just predefine the screens in the ROM itself, then you can just copy right out of them when you need to erase.
-
I'm not sure if the cartridge binary format created by Asm994a is a true machine code hex image that can be written to EPROM. It could be some file format that the Cory (the guy who made Win994a) made up and that Classic99 happens to read. I'm going to find out though, since I have all the equipment and one of Jon's new 64K cartridge boards. retroclouds should be able to chime in on this though, since he made PitFall into a cartridge, and I'm sure on Jon's site (hexbus) he details the process, I just have not looked yet.Classic99 doesn't read any of the custom formats that Cory created because he refused to share details of them, and they were too complex to unwind in an evening. It is unfortunate because his cartridge format is very nice. We will have to repeat his work and add description, manual, and cover picture fields to the MESS RPK format instead (the nice part of using XML is we can do that
).The cartridge format that Win99Asm outputs does appear to be a proper TI-formatted cartridge image.
-
Filenames are not case sensitive in Windows (normally), so the uppercase C shouldn't matter (existance, yes, case, no). I've just tested here to make sure lowercase works, too, and it seemed okay.
Otherwise looks good!
-
The crash turned out to be an uninitialized critical section.. Seven reports it in the debug log then just continues merrily along, while XP (and probably older versions) crashes. Thanks to everyone for the bug reports, and Mark for testing for me. Now I know how to check for these before I release (since even under the debugger they get ignored!!)
The fixed version (340a) is up and ready to go: http://harmlesslion.com/software/classic99
-
No, that's reality. When you type RUN at 4AM and Owen appears on your screen, wearing a loincloth and singing a country-fied version of "Happy Birthday, Mr. President"... THAT'S a hallucination.
I hope.
GAH! 2 minutes to 4am, I am shutting down the computer NOW!!!
-
Since a lot of people here are using it, I'll note that Classic99 340 is up now at http://harmlesslion.com/software/classic99. You'll find the full changelist there but I snuck in a few things people here asked for, like the window sizing options, better debugger support, and plenty more.
-
I was working on a shooter with crosshairs. Well, before thatFunny thing was, that was my first goal for this contest, but I assumed we'd be able to poke in a little assembly support, so when that was nixed I dropped it.
This is another fine looking entry! You guys are all pretty good artists!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
SSGC #3 DSAPSC
in TI-99/4A Development
Posted
No wonder you think I have nothing implemented in my emulator.. that version is almost a year old. Why doesn't the new version run? It still runs on Win98 (or at least is supposed to).
You're missing so many fixes it isn't even funny.. but if the newer versions don't work I'd like to know why.