I have recently started using VICE, specifically x64sc, and I was thinking of coding a game for it. However, I know almost nothing about what I want to do, and the manual isn't very helpful either. Some issues are particularly hard to overcome, and so far I can't find any solution
How do I copy files from a 1541 to an FD-4000? I was going to compile multiple basic extensions together to create a sort of all-in-one extension, but I don't know how to do that either.
How do I replace the kernal ROMs? My intention with this is to implement a fastloader that will work with a virtual FD-4000.
How do I get a virtual FD-4000 to work in VICE?
How do the tape images work? So far I haven't been able to find a conclusive answer.
I have downloaded some basic extensions, but I am not sure whether they are all compatible with the C64. As such, I would like to know information about the following programs, primarily if they are compatible.
apsoft-64
basic lightning v1.2
basic4.0
Basic expansion 4.5
c64 basic v3.5
DotBASIC
Game BASIC
Graphics basic
laser basic
metabasic
metabasic plus
modem basic v1.2
northcastle structured basic v1.7
tape master pro 2
ultra basic
Please let me know is there is a more appropriate place to post this.
Related
I want to learn about using TPM in embedded Linux on ARM for secureboot, TrustZone etc. But I'm currently lost finding a good starting point.
I used the search engines and read some stuff like "DEN0006D_Trusted_Board_Boot_Requirements" and "Infineon-ISPN-Use-Case-Secured-boot-for-ARM-processor-platforms-ABR-v01_00-EN". But nothing which really helped me gaining knowledge.
Either I used the wrong searching words or the information is mainly closed. The most stuff I found is about TPM and Windows...
Can someone recommend any webpage, book, video or something else to start?
Edit: Beside the things in the solution, I can recommend the free open book "A Practical Guide to TPM 2.0" https://link.springer.com/book/10.1007/978-1-4302-6584-9
I was using TPM lately on an embedded Linux and it's really a hard topic.
If you are talking about TPM itself, the first thing is which version you are using.
I am assuming that you are using TPM 2.0.
A good starting point for me was: tpm-js. You can use this tool
to learn a few things about TPM. You can browse sources of this project to
get a little deeper knowledge.
Then you can use Tpm2-tss library. Only a few months ago they
implemented the FAPI layer that simplifies the whole development.
And also there is a TPM 2.0 architecture doc that can help you a
lot, but I don't think it is a good starting point.
The last and very good source of information for me ware the people behind tpm2-tss library. Ask them on the tpm2-tss Git-Hub page.
I don't recommend you to use tpm2 tools. There ware a lot of changes lately and it will be really confusing for you in the beginning. First you need to learn the differences between hierarchies and the difference between primary key and it's child keys. A lot of these information you will find in tpm-js.
a previous relevant question from me is here Reverse Engineering old paint programs
I have set up my base of operations here: http://animatorpro.org
wiki coming soon.
Okay, so now I have a 300,000 line legacy MSDOS codebase. It's sort of a "be careful what you wish for" situation. I am not an experienced C programmer. I'm not entirely inexperienced either, but for all intents and purposes I'm a noob to the language and in particular the intricacies of its libraries. I am especially ignorant of the vagaries of the differences between C programs written specifically for MSDOS and programs that are cross platform. However I have been studying this code base for over a year now, and this is what I know about Animator Pro:
Compilers and tools used:
Watcom C compiler
tcmake (make program from Turbo C)
386asm, a specialised assembler for the Phar Lap dos extender
and of course, the Phar Lap dos extender itself.
a selection of obscure dos utilities
Much of the compilation seems to be driven by batch files. Though I have obtained copies of all these tools, I have not yet succeeded at compiling it. (though I have compiled its older brother, autodesk animator original.
It's got a plugin system that replicates DLL before DLL's were available, based on REX. The plugin system handles:
Video Drivers (with a plethora of included VESA drivers)
Input drivers (including wacom tablets, and keyboards)
Drawing Tools
Inks (Like photoshop's filters, or blending modes)
Scripting Addons (essentially compiled scripts)
File formats
It's got its own script interpreter named POCO, based on the C language- The scripting language has enough power to do virtually all the things the plugin system can do- Just slower.
Given this information, this is my development plan. Please criticise this. The source code is available in the link above, so you can easily, if you are so inclined, assess the situation yourself.
Compile with its original tools.
Switch to using DJGPP, and make the necessary changes to get it to compile with that, plus the original assembler.
Include the Allegro.cc "Game" library, and switch over as much functionality to that library as possible- Perhaps by simply writing new video and input drivers that use the Allegro API. I'm thinking allegro rather than SDL because: there is a DOS version of Allegro, and fascinatingly, one of its core functions is the ability to play Animator Pro's native format FLIC.
Hopefully after 3, I will have eliminated most or all of the Assembler in the project. I say hopefully, because it's in an obscure dialect that doesn't assemble in any modern free assembler without significant modification. I have tried them all. Whatever is left gets converted to assemble in NASM, or to C code if I can define the assembler's actual function.
Switch the dos extender from Phar Lap to HX Dos http://www.japheth.de/HX.html, Which promises to replicate as much of the WIN32 api as possible. Then make all the necessary code changes for that to work.
Switch to the win32 version of Allegro.cc, assuming that the win32 version can run on top of HXDos. Make any further necessary changes
Modify the plugin system to use some kind of standard cross platform plugin library. What this would be, I have no idea. Maybe you can offer some suggestions? I talked to the developer who originally wrote the plugin system, and he said some of the things it does aren't possible on modern OS's because of segmentation restrictions. I'm not sure what this means, but I'm guessing it means all the plugins will need to be rewritten almost from scratch.
Magically, I got all the above done, and we can try and make it run in windows, osx, and linux, whilst dealing with other cross platform niggles like long file names, and things I haven't thought of.
Anyone got a problem with any of this? Is allegro a good choice? if not, why? what would you do about this plugin system? What would you do different? Is this whole thing foolish, and should I just rewrite it from scratch, using the original as inpiration? (it would apparently take the original developer "About a month" to do that)
One thing I haven't covered above is the text/font system. Not sure what to do about that, but Animator Pro has its own custom font format, but also is able to use Postscript Type 1 fonts, and some other formats.
My biggest concern with your plan, in a nutshell: Your approach seems to be to attempt to keep the whole enormous thing working at all times, tweaking the environment ever-further away from DOS. During each tweak to the environment, that means you will have approximately a billion subtle assumptions that might have broken at once, none of which you necessarily understand yet. Untangling them all at once will be incredibly painful.
If I were doing the port, my approach would be to disable as much code as possible to get SOMETHING running in a modern environment, and bring the parts back online, one piece at a time. Write a simple test harness program that loads a display driver and draws some stuff, and compile it for DOS to make sure you understand the interface. Then write some C code that implements the same interface, but with Allegro (or SDL or SFML), and make that program work under Windows or Linux. When the output differs, you have a simple test case to work from.
Your entire job on this port is swapping out implementations of various interfaces and functions with completely new ones. This is a job that unit testing excels at. Don't write any new code without a test of some kind that runs on the old code under DOS! Make your potential problems as small and simple as you possibly can. Port assembly code instead of rewriting it only if you're reasonably confident that it will actually make your job easier (ie, algorithmic stuff that compiles fine with few tweaks under NASM). Don't bite off a bigger piece than you can comfortably fit in your brain at once.
I, for one, look forward to seeing your progress! I think what you're attempting to do is great. Thanks for doing it.
Hmmm - I might approach it by writing an OpenGL video "driver" for it. and todays machines are fast enough with tons of ram that you could do all the pixel specific algorithms on main CPU into a back buffer and it would work. As the "generic" VGA driver just mapped the video buffer to a pointer this would be a place to start. There was a zoom mode in the UI so you can look at the pixels on a high res display.
It is often very difficult to take an existing non-trivial code base that wasn't written with portability in mind - you mention a few - and then try to make it portable. There will be a lot of problems on the way. It is probably a better idea to start from scratch and rewrite the code using the existing code as reference only. If you start from scratch you can leverage existing portable UI solution in your new project like Qt.
I'm a student with a bit of experience in Java and C++ (one semester each)
Currently, I'm going through K&R and working on the exercises in the book. However, I was thinking of what I could work on over the summer since I'm almost done with K&R and I will have a lot of free time soon.
I really like building command line applications so I was thinking of getting involved with the coreutils project somehow. My question is, is it too early for me to be messing with coreutils? Should I be working on something a bit simpler perhaps? I'm a bit new with the Linux/Open source world if that matters but I'm really enjoying it.
I've done some project euler problems and I don't really like it that much.
Download the Nethack sources. Play it. If you ever get past that stage, then add some new and interesting monsters, weapons, traps and other objects.
https://openhatch.org/search/
http://sourceforge.net/people/
http://www.fsf.org/campaigns/priority-projects/
http://savannah.gnu.org/people/?type_id=1
You can do various other things with C:
Use various data structures like Link-list, tree, hash, heap
Try coding various algorithm implementation
Play with various string manipulation
Work with basic system and socket programing
List goes on..
There are (I'd argue) probably only a couple of places where C is still used extensively in preference to C++, so if you want to make a difference in the Open Source world I'd recommend thinking about working in one of the following areas:
Device drivers, and indeed most aspects of OS kernels.
Interfaces to scripting languages (Python, Perl, Lua etc.)
In both cases, C++ has no significant advantage, or some significant disadvantages, over C.
I agree absolutely with Mark's comment above that it is difficult to join a mature project. I have recently been trying to get a Haskell binding put together for SWIG, and it has proven to be pretty tricky - and I say that with over 20 years of C and about 15 of C++ behind me!
The problem is that mature codebases usually are not so clean, and this means that it can be difficult to understand how things hang together.
If you have the case, working on ARM device such as a Pandora or one of the other small embedded devices you can pick up is a lot of fun, and will teach quite a bit. In many cases what you are looking for is a device with a 'community' Linux port, and for many of these there are some quite basic components which are not yet working.
Good luck, and have fun!
I agree with Jeremy O'Donoghue's answer (since I am also a Mobile Device developer). Go install a 32-bit linux distro (if you don't already have), and start hacking Android Source Code.
There are many mailing-lists dedicated for the Android and you might try discuss some idea from there.
And there is also Google Summer of Code if you can make it
I'm trying to find a basic example, tutorial, or blog post on how to write a printer port monitor. I downloaded the Windows DDK and dug through localmon, but it appears that this sample is much more complex than just the nuts and bolts basics and from my understanding it is a bit different than an OEM port monitor because of how it handles the registry key and port enumeration. Does anyone know of a blog post, tutorial, or even book that walks the reader through the basic code to get one up and going? I've found a few links talking about the conceptual stuff, but nothing that is hands on code.
I can recomend http://www.codeproject.com/KB/printing/wpa.aspx, which describes how to write a printer driver and also has good hints about what's necessary to build a port monitor.
But my opinion is that a good tutorial in this area is not available on the Internet (I would be glad to find somebody who can show me that I'm wrong). So, when I had to deal with this task I was forced to do it the hard way: I've read carefully the MSDN explanations starting from this point: http://msdn.microsoft.com/en-us/library/ff561109.aspx. In parallel with reading MSDN I also checked the code in DDK you mentioned and try to understand it. I'm sure this solution could also work for you.
I wrote mine from the specs, there aren't really that many API's to implement.
The one thing that regularaly trips people up is EnumPorts, the spooler allocates enough memory for ALL the ports, not just yours. So you need to make sure you fill any strings from the end of the spoolers buffer, don't put them straight after your structures.
It doesn't say so in the specs but you can safely put the UI and Server functions in the same DLL.
It's also possible to create a single port monitor that supports NT and the later Windows 2000 type port monitors.
The code in RedMon is much easier to read than the localmon example, it's worth looking at before you start. It's quite nice because you can compile it in VS, you don't need to use the DDK to build it.
I have been over that exact same territory for a serial printer. About the best example I found was this article in Dr Dobbs Journal. The good part is that both a serial port driver and the user-space control program are covered and the project can also be used as an example of how to set up Visual Studio to compile a driver. This is also something a little difficult to find information about. The article discusses an old NT style driver, which worked well for me on XP.
There are quite a few good articles on CodeProject about writing drivers and programs to interact with them. They include source code and most deal with the newer WDM and WDF style drivers.
OSROnline is another good source, especially for discussion of specific issues and common mistakes. They also have some great utilities you will need.
Some of the most clearly written and understandable driver code I came across was Mark Russinovich's sample code. Although Microsoft withdrew all of the source when they purchased Sysinternals, some of the best examples can still be found cached here and there.
Drivers are pretty interesting. Whatever else you do though, do it in a virtual machine. Really.
I'm working on a small application and thinking about integrating BLAST or other local alignment searches into my application. My searching has only brought up programs, which need to be installed and called as an external program.
Is there a way short of me implementing it from scratch? Any pre-made library perhaps?
Does it have to be in C, or would C++ also be OK? If so, you might want to look at the SeqAn library here.
This is a topic which has also to do with reproducibility of results: it is always better to use the raw blast binary provided by NCBI or UCSC, because it will make your results easeir to reproduce by other scientists and will save you a lot of time spent on writing tests (more time than you can imagine).
For the day-to-day work I have often used exonerate, a tool written in C which can do both global and local alignment, has a simple unix-like interface, and doesn't require to format your input as with blast.
Moreover, take in mind that people usually use a combination of makefiles and scripts to define a pipeline, instead of calling everything from a script: most programming languages are not good to define pipelines, while automated build tools like Make are not useful for scripting tasks. Have a look at these examples: http://skam.sourceforge.net/skam-intro.html http://swc.scipy.org/lec/build.html
I just stumbled across the thing I would have wanted: The NCBI C++ Toolkit. Thanks for all the suggestions though.
The BLAST algorithm was implemented ~20 years ago, it is now a very big algorithm and I cannot imagine it can be easily implemented from scratch. You can try to learn about it when looking at the sources of the 'blastall' program in the NCBI toolkit.
A simpler pairwise algorithm (Swith Waterman, Needleman-Wunsch )should be easier to implement:
Computational Molecular Biology: An Introduction has code for Smith-Waterman and other dynamic programming alignment algorithms.
I use NetBLAST through the blastcl3 client binary. I believe that the blastcl3 binary is a pretty thin client for the NetBLAST web service.
If so, it shouldn't be too hard to sniff the packets and implement your own client. Depending on your use case, this might be faster/easier than implementing your own alignment algorithm. It does, however, introduce a dependency to NCBI's web services.
http://www.ncbi.nlm.nih.gov/staff/tao/URLAPI/netblast.html
I posted a similar question (running BLAST (bl2seq) without creating sequence files)
Basically, the answer I came up with was running this command:
bl2seq -i<(echo sequence1) -j(echo sequence2) -p blastn
That pipes the result of the echo command to the bl2seq (blast 2 sequences) program.
But I couldn't get it to work via calling system from Python