rje
-
Content Count
17 -
Joined
-
Last visited
Posts posted by rje
-
-
If you look at the full size version of the head on image, you can just about make out 4 letters across the middle of the cartridge that look like 'L' 'O' (blur) 'O'
It could be a LOGO cartridge.
Interestingly, according to the seller supplied specs page, it appears to be a rather high spec too
Especificaciones
* processor speed: 13.295 MHz
* RAM: 2 MB
* graphics processor speed: 25.59 MHz
* Polygons per second: 10000 Million
* Maximum number of colours: 17
-
Larry, what do you need a 720-sector ramdisk for? Ramdisks usually use the entire banks of ext memory. An ext bank is 16k. Therefore, a 6-bank ramdisk should do: it will contain 768 "physical" single-density sectors, which makes 762 free sectors in SpartaDOS format (or 378 in DD), or 756 in AtariDOS format, enough to fit all the files from a 720-sector single density diskette.
Thanks to all for the additional examples. I'll check out ramdrive. Think I'll pass on SuperDos...
QMEG certainly sounds interesting, although I've never used it very much.I also thought of another possible example -- since you can make an MIO ramdisk of any size in increments of 32K, it seems likely that a 720 sector ramdisk, 90 or 180K could be set up from the MIO configuration menu. I don't have an MIO set up right now, so I currently can't test that assertion.
There is a very abbreviated description of the USP OS here:
http://www.nleaudio.com/css/products.htm
Hi drac030-
No, I don't really need it for anything in particular. With the hard drive partitioning available now in multiple sizes, it is just about as useful. As with lots of things that were very neat and useful in 1990 (or so), they are not quite so useful today. But "back in the day" it was very handy to be able to mirror a real drive (and swap the drive to be D1: or perhaps D2:) to allow for playing games that made a lot of disk accesses. The USP OS allowed a lot of flexibility. In general, I find that swapping drives around is very useful, and both the MIO and Black Box, APE, and the USP OS all allowed this. Perhaps there are also others that allow this?
At any rate, I don't have a USP installed in a machine currently, but I'm thinking about putting one back in service.
-Larry
So Ramdrive can:
- set up one or more Single, Enhanced and Double density disks, single or double sided (memory allowing), or custom sizes
- boot from a ramdisk
- swap ramdisks and real drives around on the fly, e.g. make the ramdisk D1: and your real drive D8: if you wanted without having to reboot
- made to co-exist with the MyDOS and Atari DOS ramdisks
- use as much or as little of your extended RAM as you want, right down to using the RAM under BASIC as a small 8K ramdisk (not much use, but hey!)
- copy any files or sectors you want across to the ramdisk on initialisation
- modify sectors on the ramdisk on initialisation, useful if the software you want to use needs some tweaking before it will run from ramdisk
- write protect ramdisks (useful for easily testing how the software you're writing behaves if it can't save to disk, and for software that will only boot from a write protected disk)
One thing I remember using it for was to copy files between DOS 2.5 and MyDOS Enhanced Density disks, the two formats were slightly incompatible so you had to be careful which way you copied files. Using Ramdrive I would set up 3 ramdisks, one with MyDOS, one with DOS 2.5 and a third one for data. Boot from ramdisk in to MyDOS, read/write some files between the data ramdisk and a real MyDOS disk, boot from ramdisk in to DOS 2.5 read/write some files between the data ramdisk and a real DOS 2.5 disk, etc. If at any time you made a mistake and the data ramdisk got messed up, just reformat it and continue.
-
The only 720-sector ramdisk that I am familiar with is created by the CSS UltraSpeed Plus OS. It creates by default a 720-sector ramdisk in single density (assuming that you have an expanded machine). I'm not sure what it creates (if anything) on a stock 130XE. Again, assuming that you have adequate ram (say a 320K XE) it can also create a 720-sector DD ramdisk. By default, the ramdisk is D4: but can be other numbers, including D9: by running a small CSS utility at boot-up. I haven't used this OS in a while, but IIRC, this ramdisk can also co-exist with the normal MyDos ramdisk which is frequently set up as D8:.
Are there any other existing programs that can create a 720-sector ramdisk (which can mirror a real floppy)?
-Larry
Hi Larry,
Ramdrive 1.0 is supposed to handle ramdisks of any size (well up to 8 bank bits worth) and of just about any banking scheme (provided the bank register is just one byte). According to the notes you can program it to handle 16K, 32K, and 64K bank sizes.
Unfortunately I had trouble making it work with my former Wizztronics upgrade (256K total) and also my current Hias/Bernd SRAM upgrade (mine is hard-wired to 512K extended memory).
I couldn't seem to get the parameters right.
Perhaps you can figure it out.
I don't know if ramdrive 1.0 is SpartaDOS/SDX friendly. I'm primarily a MyDOS user so I never even tried the combination.
You can find the ATR here.
- Steve Sheppard
It won't work with any DOS that uses the RAM under the OS, meaning most versions of SpartaDOS are out, but it should work with most other DOSes. I remember getting it to work with Atari DOS 3, running DOS 3 from a ramdisk made it a bit nicer to use - no more disk swapping when running certain commands. =)
If your memory upgrade uses a standard banking scheme (16K banks switched using PORTB - 54017) then it should work out of the box using one of the .CFG files, e.g. RAMD64K.CFG for a 64K ramdisk. Basically the .CFG file allows you to tell Ramdrive how much RAM you have, how to access it and how big to make the ramdisk(s), and the .CPY files allows you to format the ramdisk(s) and copy files over to them. Technically you could just use the .CFG file and then format the ramdisk and copy files across from your DOS menu. All the gory details are still available at:
-
I not even sure if the Atari can do the Gif,or Jpegs,GIFs and JPEGs are do-able, rather than displaying them inline you could display the ALT text or filename as a link, selecting the link then saves the browser's current state to RAMdisk, downloads the image and launches APACVIEW (for GIFs) or JpegView (for JPEGs). When going back, open up the browser again and restore its state from RAMdisk. JpegView is open source so it could be modified to integrate more closely with the browser.
It'd take some extra RAM and it'd be slow (especially with JPEGs), but it's not impossible.
Also, the 16-bit sound idea has, in a way, also been applied to graphic modes on the Atari, search the forums/internet for APAC, HIP, RIP, TIP, CIN graphic modes. The basic idea is to draw an image using 2 or more of the Atari's existing graphics modes and then alternate between the modes. Because of the way the human eye works, it gives the appearance of improved resolution and/or more colours across the image.
-
I've been thinking about the changing 9 registers in one line thing as it relates to CpegView for a while now (as in on and off for the last couple of years), and while 9 truly independent colours per line would be nice I think it's not an absolute necesity *BUT* having said that, I've only been looking at it from the point of view of improving displayed JPEGs (i.e. photographs) rather than computer generated line drawings which may suffer a bit more.
A few thoughts on this:
If your resolution is high enough (or you stand far enough away from the screen
) you can approximate colours by dithering, basically draw the current pixel in the closest colour currently available and then adjust the colours of the pixels around it to compensate, e.g. if you haven't got the exact shade of blue you want, then the current pixel may end up being a darker shade of blue than it should be, but the surrounding pixels will be a lighter shade of blue to compensate.My guess is that you could get some worthwhile improvements just by changing 4 colour registers during the HBlank, that would give 8 (maybe even 9 if you really wanted to) colour changes over two lines. There will be some "bleeding" of colour across the boundaries, pixels that should have been changed one line earlier but weren't. That would be more of a problem for line drawings than photographs, but it may not be so bad if you're a bit clever in chosing which registers to change, maybe changing the 4 least frequently used colours on a the previous line into the 4 most frequently used colours on the next line that aren't already loaded into a register, then repeat.
It's also unlikely that you'll need all 9 colours on both the right hand side of the previous line and the left hand side of the next line. So you can start changing registers before the HBlank and continue changing them after the scan line has started drawing. For any given line, figure out the first and last places each register is used and then prioritise the register changes to get as many changes in as possible. If you do happen to need a colour that's not available yet then either skip it and wait for it to (hopefully) appear on the next scan line, or apply some dithering.
CpegView already does dithering to a set of precalculated colours, it doesn't change colour registers but I think it can do that using one or more of those approaches without taking too much of a preformance hit, the biggest problem there is deciding what colours to use.
Another approach may be to look for ways of reducing the amount of flickering in interlaced modes, the biggest problem with interlacing is that large areas of a single colour, especially a bright colour, flicker more noticeably than smaller areas of dark colours. There may be a compromise to be had there, where some of the colours that are possible are sacrificed by using the same colour for both screens in exchange for less flickering. Maybe even using PMGs to fill in some of the gaps, and/or help cover any boundaries where there's a sharp change in colour. (JpegView/CpegView use PMGs to hide the jagged left and right edges in HIP/RIP/TIP mode)
None of these approaches are perfect, but they may be good enough to get some improvements.
-
CpegView saves in the older CIN format, 192 lines. I tried loading them in Lepix 0.2.0 and it has options to load and save both types of CIN file, so it should be possible to convert between them.
I could add support for saving in the 200 line CIN format to the next version on CpegView.
-
Another problem.As source files I use pictures of 320x200 pixels as suggested by the author but the program cuts the last ~15 lines of the source files.
That's a bug, I've had a look at it and we're losing the last 8 lines in most modes and the last 16 lines in TIP.
So for now make that 320x184 for TIP images. I'll get that fixed for the next version
Have you solved the problem?
I've fixed the problem with the last 16 lines being lost, but I've not been able to track the other problem down
-
Thanks! This is exactly the upgrade that was needed.I have noticed a problem when using the Xtended RAM though. I get green bands through the picture. It works fine when using the RAM under the OS. I am testing this on an NTSC 130XE, using the 320KB Peterson upgrade (mem upgrade is working correctly) and MyDOS 4.53.
I've not been able to reproduce this problem, does it happen with all images? Are you reading the source image from a floppy? Can you send me a copy of the image?
Thanks,
-
Hmm,I have scanned more than 300 girl-pics and saved/converted them to 320x200 pixels 24bit JPEG`s. Whenever I load a couple of them into the CPEGview 0.5 and convert them a) to APAC (Gr. 9+11) mode and b) RIP32 (Gr. 9+10) mode, I notice there is no difference visible in resolution or number of colors.
...
CPEGview lets you choose between RAM under the OS and eXtra RAM - but does it require a Ramdisk driver to use the extra RAM or does it have its own driver to access the extra RAM on my 576k XL ?!? -Andreas Koch.
I had a look at this, and it's not so much a bug as a result of the way RIP images are being generated. If you look at the RIP images in an emulator and pause the screen, you can see that alternate lines are offset by 1/2 pixel, while the APAC images are not.
The problem with RIP is that you're limited to using 9 colour values [per line]. The best way of generating a RIP image would be to select the best colours to use based on the colours in the image, and then use those. But that involves figuring out the best colours to use for each image. For the time being I've chosen a fixed set of colour values, so it generates images that are OK, but not as good as they could be. Improving that is a task for the next version. =)
No extra RAM driver is required, it accesses an extra RAM bank directly and will work with any XE compatible memory extension. The flip side of that is that it may corrupt your ramdisk if you're using one at the same time.
-
Another problem.As source files I use pictures of 320x200 pixels as suggested by the author but the program cuts the last ~15 lines of the source files.
That's a bug, I've had a look at it and we're losing the last 8 lines in most modes and the last 16 lines in TIP.
So for now make that 320x184 for TIP images. I'll get that fixed for the next version
-
Does anybody have description, how to create RIP graphics mode and how to efficient draw to it?I need a resolution 160x192 with 16 independent colors. (it does not matter that it is interlaced)
And if it is possible the graphics mode with fastest (easiest) drawing in it.
What graphics mode is best for this requirements?
RIP, CIN? any other?
If you want to see some working code, the source code to CpegView is available. It can convert JPEGs to RIP, TIN, CIN and APAC, and save images in RIP, TIP and CIN formats.
16 truly independent colours isn't possible in CIN or RIP because you're limited to how many colours you can display on a single line, but depending on what you're planning to do, they may be close enough. APAC (Any Point Any Colour) is limited to 80 pixels horizontally, but does give you 256 colours that you use anywhere on the screen.
Vertical resolution is variable, I've used 192 here but you can go higher, CpegView uses 200.
CIN alternates between a GR.15 screen and a GR.11 screen. The GR.11 screen gives you 16 hues at 80x192, the GR.15 screen gives you 3 independent colours plus the background colour at 160x192. By switching quickly between both screens you can get the appearance of 160x192. You can also change the GR.15 colours on each scan line, to increase the number of colours available across the whole image.
RIP alternates between a GR.9 screen and a GR.10 screen. GR.9 gives you 16 levels of brightness in a single colour, GR.10 gives you 8 independent colours + background. The GR.10 pixels are also shifted horizontally by 1/2 pixel with respect to the GR.9 pixels, so you get the appearance of 160x192. You can change some of the GR.10 colours on each scan line, to increase the colours across the whole image.
TIP uses GR.9, GR.10 and GR.11, the GR.9 and GR.10 modes are used to give the appearance of 160 pixels horizontally with around 30 levels of brightness, GR.11 adds the colour to the image. The lines alternate so you get: ... GR.11, GR.9 + GR.10, GR.11, GR.9 + GR.10... going down the screen. This limits you to half the vertical resolution, so you'd get 160x96 or so, but you can place any of the available colours anywhere on the screen.
None of the modes fully meet your requirements, so it's hard to say what the best mode is without knowing what you want to do with it, but I hope that helped some.
-
Sometimes I get error 164 when I try to convert jpeg files.What does it means?
It's a DOS error, the exact meaning depends on which DOS you're using, but 164 is usually a corrupt file.
Try copying the file to another disk (or ATR or ramdisk) using the DOS copy command, if that still gives an error 164 then something went wrong when you copied the file on to your disk, unless it worked before and then suddenly stopped working.
The best size for images for TIP mode is 320x200 pixels
Thanks for the kudos guys, let me know if you find any bugs :-)
-
Atari 800, because it was built like a tank. The extra shielding would be really useful.
-
Version 0.5 of CpegView, the Atari-8 Colour JPEG viewer, is now available:
http://rjespino.tripod.com/8bit/colrjpeg/colrjpeg.html
http://www.angelfire.com/80s/rjespino/8bit...g/colrjpeg.html
CpegView is based on the C=64's Juddpeg decoder written by Stephen L. Judd.
Changes since the previous version:
* Added TIP display mode
* Added RIP display mode
* Added support for saving in CIN, TIP and RIP modes
* The viewer can now use extended RAM instead of the RAM under the OS on a 128K or more machine
* Added support for SpartaDos on 128K or more machines
* Image offset values can be changed by pressing the arrow keys while the image is displayed
* Reduced the amount of colour flickering while decoding
* Small speed improvement
-
Hi Andreas,
Well, I've tried that, redisplaying the same picture in different modes, redisplaying the same picture in the same mode, displaying a different picture in same/different modes, etc.
I suspect there's a difference somewhere, maybe it only happens if images are a certain size, or if the images use restart markers, or if there's a particular combination of encoding options being used. I've tried using a range of different images and still no luck.
The difference could even be down to the version of DOS being used on the Atari, or whether the files are being read from a physical drive, from a ramdisk, etc. It'd be good to track down the exact combination(s) that cause the problem
If it's that bad, then I'll change the colour flickering for something else
Not sure if I'll have time to add the save option before the next release, but it will definitely be in the one after that.
The next release will add TIP and RIP modes, as well as the option of using extended memory instead of the RAM under the OS.
-
Hi all,
I'm looking at releasing a new version of cpegview in the not too distant future, but I'm having a hard time reproducing a bug that I really want to fix in the next release.
Some people have reported stripes or lines appearing on images, the first image they display works, but any images after that have the lines. I've tried with various images and setups on emulator and real hardware but had no luck in reproducing it.
Has anyone here seen this? Have you got an image or two that definitely cause the bug to happen?
Thanks
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Off topic, but anyone here diabetic. It just closed my career
in Atari 8-Bit Computers
Posted
I've often heard it said that having diabetes is a bad thing to happen to you but being diagnosed is a good thing. It sucks right now but being diagnosed early has its blessings, many people struggle with it for years before being diagnosed by which point a lot of damage has already been done to their bodies. Being diagnosed early means you have a better chance of avoiding problems, and being fit and disciplined as I'd guess you are helps with keeping it under control. If you're already following a healthy diet and keeping fit then you're a good way towards keeping it under control.
For those that are uncomfortable with injections, insulin injections aren't as bad as most people think, by the same token making small holes in your fingers to test your glucose levels can at times be more uncomfortable than the injections.