Jump to content

Recommended Posts

Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand. It might happen someday but not likely soon. If you have trouble with copy and paste due to the windows repainting, that's what the 'freeze' button is for.

 

http://www.wxwidgets.org/

Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand. It might happen someday but not likely soon. If you have trouble with copy and paste due to the windows repainting, that's what the 'freeze' button is for.

 

http://www.wxwidgets.org/

 

Needs more description. ;)

 

I was thinking more along the lines of Mono, myself. ;)

 

Looked at it a little more closely, I can't use it anyway. It's LGPL and I don't license my code that way.

Edited by Tursi

Hmmm... I just tried the new version, and the speech (in Parsec, which I tried) still sounds as garbled as in the old version.

By the way, if you import the new speech code from M.E.S.S., I found out that the rate of 680 kHz they are running the chip at is incorrect... 640 kHz would be the correct rate since it produces the correct pitch.

 

There's no reason that general speech functionality would be any better or worse. I only fixed a small bug in the init code that prevented it from speaking at all in some cases.

 

I'd only be taking the decoder code from MESS, I have my own audio system. I'll remember to look at that, but as I always say, I don't like the speech synthesizer and supporting it is low on my priority list. ;)

Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand. It might happen someday but not likely soon. If you have trouble with copy and paste due to the windows repainting, that's what the 'freeze' button is for.

 

http://www.wxwidgets.org/

 

Needs more description. ;)

 

I was thinking more along the lines of Mono, myself. ;)

 

Looked at it a little more closely, I can't use it anyway. It's LGPL and I don't license my code that way.

 

An API for tapping the classic99 debugger functionality could perhaps be a solution.

That way the debugger could run in an own process and could be written in MONO, java, ...

 

I know there is an interface with bug99 by Thiery Nouspikel, but have to admit I really couldn't get it to work

properly. It requires modifying your assembler program, which I didn't like that much.

The reason I added Bug99 support was because it was a fully functional, spec'd out debugger.

 

The Classic99 debugger doesn't do much on its own, it's tightly tied to the emulation. But if you wanted to write a spec for what kind of interface you are talking about, and write a test/sample application that uses it, then we can talk about it and maybe negotiate it to something feasible. I have no desire to do it just because, because the current interface satisfies my needs. :)

Edited by Tursi
Quick question: is there any chance we can get USCD Pascal running in classic99 ? I think that at this time there is no emulator supporting USCD Pascal, not even MESS. I have the p-code card and should be able to dump the roms.

 

I already support it, it just doesn't work. ;) The ROMs are already in there, and are presumably correct.

 

However, it's pretty badly broken right now. It used to work up to the point of the first beep, at which point I was putting off more work until I supported disk images (since it doesn't use the normal file system as far as I know). Now however, it just seems to crash right away, probably I broke the paging when I removed the SDGROM. I wasn't too concerned since it didn't work before.

 

I thought PC99 supported it, though.

I would be very interested in supporting the p-code card as far as programs are concerned if there was a widely available emulator for it. Currently, given how few the p-code cards are, not many people will be able to take advantage of any new software... While PC99 does support it, it's no longer mainstream given that it is still DOS based.

Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand. It might happen someday but not likely soon. If you have trouble with copy and paste due to the windows repainting, that's what the 'freeze' button is for.

 

http://www.wxwidgets.org/

 

Needs more description. ;)

 

I was thinking more along the lines of Mono, myself. ;)

 

Looked at it a little more closely, I can't use it anyway. It's LGPL and I don't license my code that way.

 

Basically "Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand." sounds like some bull-headed excuse I would come up with. It seems that a more practical approach would be to use one of the many frameworks out there to deal with the crud of managing windows and dialogs. I have this argument with a friend of mine almost every day. He has embraced "technology" (.net mostly, but other development solutions as well) and sells a successful billing software that supports his family and gives him all the free time he wants. As for me, since I have a mental block to anything other than doing it the absolute hardest (albeit fastest and most efficient) way, but I don't have anything I'm selling and I still work a day job for someone else (an employer).

 

You are always pretty practical, so I figured you would find a cross platform window manager / framework and get on with making the emulator better... Maybe you are more stubborn than I thought. ;)

 

As for the license of wx, I don't know. I don't think that just because you *use* some LGPL software that you have to also release using that license. I think all you would have to do would be to include their license notice that acknowledges that you are using wx. Using GPL stuff does not prevent you from making closed-source commercial products, or anything in between. I could be wrong though, since I never got a project to the point where I needed to worry about it.

 

Matthew

Basically "Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand." sounds like some bull-headed excuse I would come up with. It seems that a more practical approach would be to use one of the many frameworks out there to deal with the crud of managing windows and dialogs.

 

I'd rather use MFC than one of the third party window managers. My request for additional details was not a request for potshots, but a request for why you chose that particular one. My time is limited: I can spend my two free days a month on updating the window manager to something slightly more modern so that you can do something that you can already do, but slightly more easily, or I can work on the broken timing system which is holding back all the other improvements people need. As an example. ;)

 

I have this argument with a friend of mine almost every day. He has embraced "technology" (.net mostly, but other development solutions as well) and sells a successful billing software that supports his family and gives him all the free time he wants. As for me, since I have a mental block to anything other than doing it the absolute hardest (albeit fastest and most efficient) way, but I don't have anything I'm selling and I still work a day job for someone else (an employer).

 

Not quite sure how this applies to my desire to prioritize the code I work on.

 

You are always pretty practical, so I figured you would find a cross platform window manager / framework and get on with making the emulator better... Maybe you are more stubborn than I thought. ;)

 

It's a Win32-based emulator -- how the heck would porting it to a cross-platform window manager help? Are you arguing my point that I don't currently want to spend time creating all the code to support new windows, or my dis-interest in porting to other platforms? Your quote suggests the former.

 

Unlike many projects out there, I test my code. If I want to support other platforms, then I need to test or arrange reliable testing on those other platforms as well. It's not something that I am currently interested in doing. Nobody is supporting my family through Classic99 nor will they ever, thus it does remain lower priority than things that do or may. ;)

 

The thing you seem to be forgetting in chewing me out here is that I do Classic99 because I like working on it. I do the odd request because I'm glad that people like using it. But it is not supporting me by any stretch of the imagination, and it's a long way from being my only spare-time project.

 

As for the license of wx, I don't know. I don't think that just because you *use* some LGPL software that you have to also release using that license. I think all you would have to do would be to include their license notice that acknowledges that you are using wx. Using GPL stuff does not prevent you from making closed-source commercial products, or anything in between. I could be wrong though, since I never got a project to the point where I needed to worry about it.

 

I think you should spend some time reading the licenses, and less time guessing. Facts over theories.

 

GPL absolutely prevents you from making closed-source commercial projects - in fact that's its entire point. LGPL is only slightly more permissive. If you include any code from a GPL project in your program, then that program must also be licensed as GPL. One of the strongest terms of GPL is that anyone who receives a copy of the program must also be able to receive a full copy of the source, and be licensed to distribute that source and object code as they like so long as they also license as GPL. LGPL permits specific exclusions.

 

This means that I can take any GPL package, repackage it, strip author names if I like, and call it "TursiTron". I can then sell the package for $5000. But everyone who buys a copy from me is entitled to the source to TursiTron, and likewise they are free to then give it away for free if they choose. I don't like GPL for most of my code. :)

Just published Classic99 v343 - this fixes an edge case in the S and SB opcodes - turns out that 0-0=0 + carry flag, and carry wasn't being set. Thanks to Stuart Conner for pointing this out to me. I ran a few other tests just in case and as far as I can tell, that was the only case I missed.

 

I haven't updated the notes to say so because I didn't test it too far, but this fix appears to make the 99/4 start correctly now! I'll have to work out the keyboard emulation for it, but if you are playing around with it, it has no FCTN key, and almost no punctuation keys. Just numbers and letters, and special functions are SHIFT plus a letter or number (for instance, SHIFT+Q is quit).

Thanks a bunch! Classic 99 has really evolved into the de facto standard TI emulator, and it's so easy to use!

Now when can we expect a Linux version ;)

 

Thanks, I'm glad it's helpful to people. Linux probably won't happen anytime soon, but I won't say never. I've been eyeing some cross-platform devkits and wondering what projects might be good for them. ;)

 

THIS ONE!

Thanks, I'm glad it's helpful to people. Linux probably won't happen anytime soon, but I won't say never. I've been eyeing some cross-platform devkits and wondering what projects might be good for them. ;)

 

THIS ONE!

 

I'm told it works fine under Wine, though, so, just out of curiousity, what's the advantage? It doesn't seem like much is really gained for the investment in time and support?

 

Sorry for being snippy lately, haven't got much sleep in the last long while. ;)

  • 2 weeks later...

Just a quick correction - MESS absolutely supports the P-Code card, and has for at least two revisions:

 

0000lj.png

 

(This isn't just a static shot - it is really 100% functional.)

 

Recent MESS builds have also included full (read: rocker-switch level) support for GRAM Kracker emulation.

 

I myself have my emulated TI set up with a 512K Myarc RAM card and HFDC controller driving 4 DSDD drives and a 20MB ST-220 hard drive (with MBM5 preloaded), and a cartridge switcher holding TIXB and Mini-Memory. It makes a fantastic development environment!

 

Rodney

This is really good news. I was not sure it did, and with previously only PC99 supporting the p-code card, I was holding out on producing projects on it. This certainly changes my outlook because Pascal is my absolute favorite language (yes, I immensely dislike C :D ). And if anybody gives me crap about this, I know someone on the PCjr forum who will chew you out with his arguments on why Pascal is superior :twisted:

 

Just a quick correction - MESS absolutely supports the P-Code card, and has for at least two revisions:

 

0000lj.png

 

(This isn't just a static shot - it is really 100% functional.)

 

Thanks, I'm glad it's helpful to people. Linux probably won't happen anytime soon, but I won't say never. I've been eyeing some cross-platform devkits and wondering what projects might be good for them. ;)

 

THIS ONE!

 

I'm told it works fine under Wine, though, so, just out of curiousity, what's the advantage? It doesn't seem like much is really gained for the investment in time and support?

 

Sorry for being snippy lately, haven't got much sleep in the last long while. ;)

 

 

It doesn't work fine under Wine, if that were the case then I wouldn't say anything :) Once I get the DLL's it requires from the compiler it loads without errors but it has timing issues. It runs slow as molasses on normal TI speed.

 

Greg

Thanks Greg. While there's not a ton I can do about Wine support just at the moment, KNOWING there is an issue after all is something that's good to have. What happens if you increase the frameskip in the Classic99.ini file? Classic99 hits the video system hard, if Wine is emulating any part of that it might just be the VDP updates that are killing it.

Hey Tursi... interesting problem

 

I was playing with filter modes, just seeing what's there... I switched to the highest resolution and it froze the program up. I ended the task, restarted Classic99, and it froze again. The edges of my laptop screen go black, and I get the spinning icon--- Classic99 won't start up now.

 

Any ideas? Will I have to uninstall and re-install? Ever heard of this problem before?

I looked into the Classic99.ini file and saw "Filter Mode-4". I tried changing this to "1", but it didn't have any effect, so I changed it back. I'm thinking there's more that needs to change before it'll work again, but looking into Classic99.ini, I'm thinking it can all be fixed there. Any help would be greatly appreciated... I'm missing valuable "Legends" time. hehe

There's no install, so you never have to uninstall. ;)

 

You probably selected a resolution not supported by your video card. Classic99 currently hard-codes resolutions and I noticed on some video cards that requesting a bad resolution locks up instead of failing. Change the "StretchMode" back to 0 (none) and it should come up (then you can reconfigure it again). If all else fails, rename or delete classic99.ini (depending on whether there are settings in there you want to keep) and let it create a new one.

 

Personally I never run the full screen modes, so windowed mode has a lot more test time.

 

Read through the manual to see what all the classic99.ini settings do. Filter mode is just what kind of special effects it applies to the video.

I will check that out. On this computer, I can run Eve Online in wine without frame skips.. but perhaps your program does more :)

 

Greg

 

 

Thanks Greg. While there's not a ton I can do about Wine support just at the moment, KNOWING there is an issue after all is something that's good to have. What happens if you increase the frameskip in the Classic99.ini file? Classic99 hits the video system hard, if Wine is emulating any part of that it might just be the VDP updates that are killing it.

Classic99 has always had trouble on certain systems, and I narrowed it down to how it talks to the video system of the host computer. There are a number of inefficiencies that are on my list to fix now that I know the system better and more computers are capable of higher bitdepths... right now pretty much all machines end up doing bitdepth conversions.

Frame-skip is irrelevant to timing issues on my core2 laptop and core2quad machines. Both running nvidia video cards the quad has a 275 which is more than enough horsepower..

 

Greg

 

I will check that out. On this computer, I can run Eve Online in wine without frame skips.. but perhaps your program does more :)

 

Greg

 

 

Thanks Greg. While there's not a ton I can do about Wine support just at the moment, KNOWING there is an issue after all is something that's good to have. What happens if you increase the frameskip in the Classic99.ini file? Classic99 hits the video system hard, if Wine is emulating any part of that it might just be the VDP updates that are killing it.

Would it be possible to extend the Dump RAM (F10) VDPDUMP.BIN with 8 bytes namely the 8 VDP registers ? It would then be possible for utilities to determine graphic mode, location of tables etc.

 

Yeah, that's pretty reasonable, I'll put that one near the top of the list so it gets into the next round of changes. :)

Got a few wishes (not too many) into this originally-meant-to-be-minor update to v345:

 

-Improve memory access timing by wrapping all CPU accesses (making sure the CPU always does 16-bit access)

-Fix cycle count patching in post_inc to be correct in all memory cases

-Removed extra RMW faking in certain opcodes

-Change default for "AllowTxtWithoutExtension" to false -- Windows TXT files must have a recognized extension

-Added support to read files without extension as DF128 (MUST have AllowTxtWithoutExtension set to 0 in the INI)

-Added hack to allow faking the SID back to the 9919 (not available outside of source code)

-Change interrupt flag to end_of_frame, and fix up the timing around that

-removed some old CPU memory wrapper functions that didn't do anything

-make sure we still check the VDP for redraw even if the CRU interrupt is masked (fixes rare case where screen did not update)

-Make sure the 9901 timer is not restarted when CRU bit 0 is cleared if it was not set

-Automatically set CPU Overdrive mode when pasting text

-Don't let console hardware respond to odd memory addresses

-Write VDP registers at the end of the VDPDUMP.BIN file

 

http://harmlesslion.com/software/classic99

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...